The Software Life Cycle

Inherent Problems with Software Development

Requirements are complex

The client usually does not know all the functional requirements in advance
Technology enablers introduce new possibilities to deal with nonfunctional requirements Identifying milestones and cost estimation is difficult

Requirements may be changing

Frequent changes are difficult to manage

Inherent Problems with Software Development

There is more than one software system

New system must often be backward compatible with existing system (legacy system) Phased development: Need to distinguish between the system under development and already released systems

Definitions
Software life cycle modeling: Attempt to deal with complexity and change

Software life cycle:

Set of activities and their relationships to each other to support the development of a software system

Software development methodology:

A collection of techniques for building models - applied across the software life cycle

Software Life Cycle

Software construction goes through a progression of states:

Conception

Childhood

Adulthood

Retirement

PreDevelopment
5

Development

PostDevelopment

Typical Software Lifecycle Questions

Which activities should I select for the software project? What are the dependencies between activities?

Does system design depend on analysis? Does analysis depend on design?

How should I schedule the activities?

Should analysis precede design? Can analysis and design be done in parallel? Should they be done iteratively?

Possible Identification of Software Development Activities

Requirements Analysis What is the problem? What is the solution? Problem Domain

System Design Program Design

Program Implementation Testing

What are the mechanisms that best implement the solution? Implementation How is the solution constructed? Domain
Is the problem solved?

Delivery
Maintenance 7

Can the customer use the solution?

Are enhancements needed?

Life-Cycle Model: Variations on a Theme

Many models have been proposed to deal with the problems of defining activities and associating them with each other.

The waterfall model:

First described by Royce in 1970 There seem to be at least as many versions as there are authorities - perhaps more.

Project Initialization Process Concept Exploration Process System Allocation Process

The Waterfall Model of the Software Life Cycle

Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process

Requirements Process

Advantages with Waterfall Model

1) Waterfall model is simple to implement and also the amount of resources required for it are minimal. 2) In this model, output is generated after each stage (as seen before), therefore it has high visibility. The client and project manager gets a feel that there is considerable progress. Here it is important to note that in any project psychological factors also play an important role. 3) Project management, both at internal level and client's level, is easy again because of visible outputs after each phase. Deadlines can be set for the completion of each phase and evaluation can be done from time to time, to check if project is going as per milestones.

4) This methodology is preferred in projects where quality is more important as compared to schedule or cost.

10

Problems with Waterfall Model

1) Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.

2) It is often difficult to get customer requirements explicitly. Thus specifications can't be freeze. If that case arises baseline approach is followed, wherein output of one phase is carried forward to next phase. For example, even if SRS is not well defined and requirements can't be freeze, still design starts. Now if any changes are made in SRS then formal procedure is followed to put those changes in baseline document. 3) In this model we freeze software and hardware. But as technology changes at a rapid pace, such freezing is not advisable especially in long-term projects. 4) This method is especially bad in case client is not IT-literate as getting specifications from such a person is tough. 5) Even a small change in any previous stage can cause big problem for subsequent phases as all phases are dependent on each-other
11

Verification Activities
Level of Detail Low
Requirements Elicitation Clients Understanding Developers Understanding

Acceptance Testing
Problem with V-Model: Clients Perception is the same as the Developers Perception

Analysis

System Testing Design Integration Testing

Object Design

Unit Testing

High
12

Problems with V-Model

Very rigid and least flexible. Software is developed during the implementation phase, so no early prototypes of the software are produced. If any changes happen in midway, then the test documents along with requirement documents has to be updated.

13

Advantages of V- Model

Simple and easy to use. Testing activities like planning, happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model. Proactive defect tracking that is defects are found at early stage. Avoids the downward flow of the defects. Works well for small projects where requirements are easily understood.

Advantages ---------------------1) 2)

Spiral Model (Boehm) Deals with Iteration

Importance more on risk analysis. Software is produced during early stages.

Disadvantages -----------------------------1) Spiral model is costly. 2) Should not be used for smaller projects.

15

Spiral Model

16

Activities (Rounds) in Boehms Spiral Model

Concept of Operations Software Requirements Software Product Design Detailed Design Code Unit Test Integration and Test Acceptance Test Implementation

For each cycle go through these steps:

17

Define objectives, alternatives, constraints Evaluate alternative, identify and resolve risks Develop, verify prototype Plan next cycle

Scrum Model

Basic Agile Model

Agile Model is used for the below scenarios a) Where we have unclear Requirements b) Frequent Requirements , Changes c) Technology advancements d) Environmental/Condition Changes e) New Set up of Project/Environment f) Very long span projects

Problem with Agile Model

New Project, New Environmental conditions with frequent requirement changes creates new problem, and if we use basic srum approach can deviate progress from intended plan as the process is recursive. To avoid this situation we use Agile- Scrum Model which introduces help of few people known as TPMs or PJMs and Few Documents.

Scrum --------------------------

Complete project is segregated in to small releases or Sprints. When the sprint ends, TPMs with business track the progress of project and plans the next scopes. This allows adjustments needed to project if any deviation has happened or help in sustaining pace.

More on Scrum

name taken from the sport of Rugby, where everyone in the team pack acts together to move the ball down the field

Scrum assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression Scrum is an enhancement of the commonly used iterative/incremental object-oriented development cycle

Roles

Product Owner

The Product Owner represents the stakeholders and is the customer`s voice. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, this role should not be combined with that of the Scrum Master. In an enterprise environment, though, the Product Owner is often combined with the role of Project Manager as they have the best visibility regarding the scope of work (products).

Team

The Team is responsible for delivering potentially shippable product increments at the end of each Sprint (the Sprint Goal). A Team is made up of 7 +/- 2 individuals with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). The Team in Scrum is self-organizing, even though there may be some level of interface with project management organizations (PMOs).

Scrum Master Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve

Meetings in Agile Scrum

Daily Scrum Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines: All members of the development team come prepared with the updates for the meeting. The meeting starts precisely on time even if some development team members are missing. The meeting should happen at the same location and same time every day. During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do today? Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

Backlog grooming This is the process of creating stories, decomposing stories into smaller ones when they are too large, refining the acceptance criteria for individual stories, prioritizing stories on the product backlog and sizing the existing stories in the product backlog using effort/points. During each sprint the team should spend time doing product backlog grooming to keep a pool of stories ready for the next sprint.

Sprint planning meeting t the beginning of the sprint cycle (every 730 days), a "Sprint planning meeting" is held Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team Identify and communicate how much of the work is likely to be done during the current sprint

Sprint Retrospective All team members reflect on the past sprint Make continuous process improvements Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three-hour time limit This meeting is facilitated by the Scrum Master

Terms Used in Agile Scrum

BackLogs -----------------Product backlog is the list of functionalities which we are going to implement. It consists of features, bug fixes, non-functional requirements, etc. - whatever needs to be done in order to successfully deliver a working software system. The items are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc
The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprint's stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.

Burn down The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference

Some More Terms

Scrum Team Product Owner Sprint User Story EPIC Tasks