Question

Question 1: 1. Discuss your understanding on the following software processes models based on the provided attributes: Process Models

: a. Waterfall process

b. Incremental delivery

c. Component based software development (Reuse-based)

d. Rational Unified Process (RUP)

e. Spiral Process

f. eXtreme Programming (XP) Attributes:

a. Applicability: What type of software projects are they typically applicable.

b. Rapidity of development: How fast can software be developed.

c. Quality of developed software: The quality of the end-product and the software artefacts like SRS and design document.

d. Customer/Stakeholder involvement: How much are the customer/Stakeholder involved in the process.

e. Process Visibility: How easy is to judge the progress of the project.

Question 2: Decide and explain in brief which software process would be best suitable to develop each of the following software. You can propose a hybrid process. You need to provide clear justifications for your choice. Also, list down three most important quality attributes (from the user perspective) for each of the listed software and explain in brief why it is important: 1.

A massive online course platform like Coursera, Udacity, Edx.

2. Online banking system for a bank.

3. A university software consisting of registration system, library system, student admission system, and faculty information system.

4. A calendar App for smartphones

Answer 1

1)  Waterfall process Model: The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model.

The sequential phases in Waterfall model are −

• Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.
• System Design: The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.
• Implementation: With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.
• Deployment of system: Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.
• Maintenance: here are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −

• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

Some of the major advantages of the Waterfall Model are as follows −

• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

• The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

2) Incremental delivery Model

Incremental delivery is the practice of repeatedly delivering a system into production (or the marketplace) in a series of expanding capabilities.

Incremental Model is a process of software development where requirements are broken down into multiple standalone modules of software development cycle. Incremental development is done in steps from analysis design, implementation, testing/verification, maintenance.

Each iteration passes through the requirements, design, coding and testing phases. And each subsequent release of the system adds function to the previous release until all designed functionality has been implemented.

The system is put into production when the first increment is delivered. The first increment is often a core product where the basic requirements are addressed, and supplementary features are added in the next increments. Once the core product is analyzed by the client, there is plan development for the next increment.

Characteristics of an Incremental module includes

• System development is broken down into many mini development projects
• Partial systems are successively built to produce a final total system
• Highest priority requirement is tackled first
• Once the requirement is developed, requirement for that increment are frozen

When to use Incremental models?

• Requirements of the system are clearly understood
• When demand for an early release of a product arises
• When software engineering team are not very well skilled or trained
• When high-risk features and goals are involved
• Such methodology is more in use for web application and product based companies

Advantages and Disadvantages of Incremental Model

Advantages	Disadvantages
The software will be generated quickly during the software life cycle	It requires a good planning designing
It is flexible and less expensive to change requirements and scope	Problems might cause due to system architecture as such not all requirements collected up front for the entire software lifecycle
Throughout the development stages changes can be done	Each iteration phase is rigid and does not overlap each other
This model is less costly compared to others	Rectifying a problem in one unit requires correction in all the units and consumes a lot of time
A customer can respond to each building	-
Errors are easy to be identified	-

3) Component based software development (Reuse-based):

Software has been reused in applications development ever since programming started. However, the reuse practices have mostly been ad hoc, and the potential benefits of reuse have never been fully realized. Most of the available software development methodologies do not explicitly identify reuse activities. The Application of Reusable Software Components Project of the Software Engineering Institute is developing a reuse-based software development methodology, and the current direction and the progress of the methodology work are discussed in this paper.

The methodology is based on the life cycle model in DoD-STD-2167A with refinement of each phase to identify reuse activities. The reuse activities that are common across the life cycle phases are identified as: 1) studying the problem and available solutions to the problem and developing a reuse plan or strategy, 2) identifying a solution structure for the problem following the reuse plan, 3) reconfiguring the solution structure to improve reuse at the next phase, 4) acquiring, instantiating, and/or modifying existing reusable components, 5) integrating the reused and any newly developed components into the products for the phase, and 6) evaluating the products. These activities are used as the base model for defining the specific activities at each phase of the life cycle.

This methodology focuses more on identification and application of reusable resources than on construction of reusable resources, and some enhancements in the construction aspect might be necessary to make it more complete.

This methodology has never been applied; it will be used in an application redevelopment experiment and then will be improved based on our experience.

4) Rational Unified Process (RUP)

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Rational Software originally developed the rational unified process as a software process product. The product includes a hyperlinked knowledge-base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.

Philippe Kruchten, an experienced Rational technical representative was tasked with heading up the original RUP team. This journey began with the creation of the Rational Objectory Process (ROP) in 1996, when Rational acquired the Objectory Process that had been written by Ivar Jacobson and company. This was renamed Rational Unified Process (RUP) in subsequent releases, in part to align the name with that of the Unified Modeling Language.

RUP building blocks

RUP is based on a set of building blocks and content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following:

• Roles (who): A role defines a set of related skills, competencies and responsibilities.
• Work products (what): A work product represents something resulting from a task, including all the documents and models produced while working through the process.
• Tasks (how): A task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorized into nine disciplines:

Six "engineering disciplines"

• Business modelling
• Requirements
• Analysis and design
• Implementation
• Test
• Deployment

Three supporting disciplines

• Configuration and change management
• Project management
• Environment

Four project life-cycle phases

The RUP has determined a project life-cycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished. The visualization of RUP phases and disciplines over time is referred to as the RUP hump chart.

Inception phase

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Requirements understanding as evidenced by the fidelity of the primary use cases.
• Credibility of the cost/schedule estimates, priorities, risks, and development process.
• Depth and breadth of any architectural prototype that was developed.
• Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the life cycle objective milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration phase

The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

The outcome of the elaboration phase is:

• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process.
• An executable architecture that realizes architecturally significant use cases.
• Business case and risk list which are revised.
• A development plan for the overall project.
• Prototypes that demonstrably mitigate each identified technical risk.
• A preliminary user manual (optional)

This phase must pass the lifecycle architecture milestone criteria answering the following questions:

• Is the vision of the product stable?
• Is the architecture stable?
• Does the executable demonstration indicate that major risk elements are addressed and resolved?
• Is the construction phase plan sufficiently detailed and accurate?
• Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
• Is the actual vs. planned resource expenditure acceptable?

If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is the system architecture.

Construction phase

The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments produce demonstrable prototypes.

Transition phase

The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The system also goes through an evaluation phase, any developer which is not producing the required work is replaced or removed. The product is also checked against the quality level set in the Inception phase.

If all objectives are met, the product release milestone is reached and the development cycle is finished.