Software Engineering with UML

Overview of Software Development with SSAD  

Waterfall model: - waterfall model linear representation of its face for developing a particular system in this model. These phases are:

1) Communication (requirement analysis, specification).

2) Planning (estimating, seducing).

3) Modelling (analysis, design).

4) Construction (code, test).

5) Deployment (delegacy, support, fid back).

a) This phase involve the whole working process for making a particular software for desired client.

b) Iterative waterfall model and the classical waterfall model are the two types are these model available calices. We have to follow the linear stage or phase which are available in waterfall model. But in the iterative model we can jump over from one phase to another phase.

Disadvantages of waterfall model:-

1) In real life the project are sequential.

2) Intel finished the project the working versa is not available for the customer.

3) Hardware implementation in the middle of the project is fact.

4) In this model the risk factor is not available.

Fig. 1 Iterative water fall Model 

Spiral model: - the spiral model is a step by step process it stresses on the risk factor of the SDLC.

The stages of the model are:

1) planning

2) risk analysis

3) development

4) customer assessment

a) determine objective alternative

b) evaluative alternative risk analysis

c) development and product

d) plane for next phase

From the above figure we can see that there are four parts including some loops how ever the number of loops is not fixed depending on the project. Spiral model has a special type of focus on risk factor by which it has make some difference from the other model. In this model the phases are planning, risk analysis, development and customer assessment. From the diagram we can say that first quadrant which representation and make some object and determine the analysis for a particular project. The next part deals and evaluated some alternative way by which we can achieve a simple solution. In this phase the risk analysis is also measured depending on the project.

Fig. 2 Spiral Model

RUP Rational Unified Process

with Four Major phases:- Inception , Elaboration, Construction, Transition.

The Four Phases

The life of a software system can be represented as a series of cycles. A cycle ends with the release of a version of the system to customers.

Within the Unified Process, each cycle contains four phases. A phase is simply the span of time between two major milestones, points at which managers make important decisions about whether to proceed with development and, if so, what's required concerning project scope, budget, and schedule.

Figure 1-1: Phases and Major Milestones

Figure 1-1 shows the phases and major milestones of the Unified Process. In it, you can see that each phase contains one or more iterations. We'll explore the concept of iterations in the section "Iterations and Increments" later in this chapter.

The following subsections describe the key aspects of each of these phases.

Inception

The primary goal of the Inception phase is to establish the case for the viability of the proposed system.

The tasks that a project team performs during Inception include the following:

·         Defining the scope of the system (that is, what's in and what's out)

·         Outlining a candidate architecture, which is made up of initial versions of six different models

·         Identifying critical risks and determining when and how the project will address them

·         Starting to make the business case that the project is worth doing, based on initial estimates of cost, effort, schedule, and product quality

The concept of candidate architecture is discussed in the section "Architecture-Centric" later in this chapter. The six models are covered in the next major section of this chapter, "The Five Workflows."

The major milestone associated with the Inception phase is called Life-Cycle Objectives. The indications that the project has reached this milestone include the following:

·         The major stakeholders agree on the scope of the proposed system.

·         The candidate architecture clearly addresses a set of critical high-level requirements.

·         The business case for the project is strong enough to justify a green light for continued development.

Elaboration

The primary goal of the Elaboration phase is to establish the ability to build the new system given the financial constraints, schedule constraints, and other kinds of constraints that the development project faces.

The tasks that a project team performs during Elaboration include the following:

·         Capturing a healthy majority of the remaining functional requirements

·         Expanding the candidate architecture into a full architectural baseline, which is an internal release of the system focused on describing the architecture

·         Addressing significant risks on an ongoing basis

·         Finalizing the business case for the project and preparing a project plan that contains sufficient detail to guide the next phase of the project (Construction)

The architectural baseline contains expanded versions of the six models initialized during the Inception phase.

The major milestone associated with the Elaboration phase is called Life-Cycle Architecture. The indications that the project has reached this milestone include the following:

·         Most of the functional requirements for the new system have been captured in the use case model.

·         The architectural baseline is a small, skinny system that will serve as a solid foundation for ongoing development.

·         The business case has received a green light, and the project team has an initial project plan that describes how the Construction phase will proceed.

The use case model is described in the upcoming section "The Five Workflows." Risks are discussed in the section "Iterations and Increments" later in this chapter.

Construction

The primary goal of the Construction phase is to build a system capable of operating successfully in beta customer environments.

During Construction, the project team performs tasks that involve building the system iteratively and incrementally (see "Iterations and Increments" later in this chapter), making sure that the viability of the system is always evident in executable form.

The major milestone associated with the Construction phase is called Initial Operational Capability. The project has reached this milestone if a set of beta customers has a more or less fully operational system in their hands.

Transition

The primary goal of the Transition phase is to roll out the fully functional system to customers.

During Transition, the project team focuses on correcting defects and modifying the system to correct previously unidentified problems.

The major milestone associated with the Transition phase is called Product Release.

What is RAD?

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product.

In RAD model the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery.

Since there is no detailed preplanning, it makes it easier to incorporate the changes within the development process. RAD projects follow iterative and incremental model and have small teams comprising of developers, domain experts, customer representatives and other IT resources working progressively on their component or prototype.

The most important aspect for this model to be successful is to make sure that the prototypes developed are reusable.

RAD Model Design

RAD model distributes the analysis, design, build, and test phases into a series of short, iterative development cycles. Following are the phases of RAD Model:

·        Business Modeling: The business model for the product under development is designed in terms of flow of information and the distribution of information between various business channels. A complete business analysis is performed to find the vital information for business, how it can be obtained, how and when is the information processed and what are the factors driving successful flow of information.

·        Data Modeling: The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data objects vital for the business. The attributes of all data sets is identified and defined. The relation between these data objects are established and defined in detail in relevance to the business model.

·        Process Modeling: The data object sets defined in the Data Modeling phase are converted to establish the business information flow needed to achieve specific business objectives as per the business model. The process model for any changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding , deleting, retrieving or modifying a data object are given.

·        Application Generation: The actual system is built and coding is done by using automation tools to convert process and data models into actual prototypes.

·        Testing and Turnover:The overall testing time is reduced in RAD model as the prototypes are independently tested during every iteration. However the data flow and the interfaces between all the components need to be thoroughly tested with complete test coverage. Since most of the programming components have already been tested, it reduces the risk of any major issues.

Following image illustrates the RAD Model:

RAD Model Application

RAD model can be applied successfully to the projects in which clear modularization is possible. If the project cannot be broken into modules, RAD may fail. Following are the typical scenarios where RAD can be used:

·        RAD should be used only when a system can be modularized to be delivered in incremental manner.

·        It should be used if there.s high availability of designers for modeling.

·        It should be used only if the budget permits use of automated code generating tools.

·        RAD SDLC model should be chosen only if domain experts are available with relevant business knowledge.

·        Should be used where the requirements change during the course of the project and working prototypes are to be presented to customer in small iterations of 2-3 months.

RAD Model Pros and Cons

RAD model enables rapid delivery as it reduces the overall development time due to reusability of the components and parallel development.

RAD works well only if high skilled engineers are available and the customer is also committed to achieve the targeted prototype in the given time frame. If there is commitment lacking on either side the model may fail.

Following table lists out the pros and cons of RAD Model:

Pros

Cons

·        Changing requirements can be accommodated. ·        Progress can be measured. ·        Iteration time can be short with use of powerful RAD tools. ·        Productivity with fewer people in short time. ·        Reduced development time. ·        Increases reusability of components ·        Quick initial reviews occur ·        Encourages customer feedback ·        Integration from very beginning solves a lot of integration issues.

·        Dependency on technically strong team members for identifying business requirements. ·        Only system that can be modularized can be built using RAD. ·        Requires highly skilled developers/designers. ·        High dependency on modeling skills. ·        Inapplicable to cheaper projects as cost of modeling and automated code generation is very high. ·        Management complexity is more. ·        Suitable for systems that are component based and scalable. ·        Requires user involvement throughout the life cycle. ·        Suitable for project requiring shorter development times.