CSE3050 – Software Project

Management

MODULE 2 – SOFTWARE
LIFECYCLE MANAGEMENT

SCHOOL OF CSE & IS,

PRESIDENCY UNIVERSITY,
BANGALORE

1
CONTENTS

• SOFTWARE LIFECYCLE MANAGEMENT

• SOFTWARE REQUIREMENTS MANAGEMENT
• SOFTWARE DESIGN MANAGEMENT
• SOFTWARE CONSTRUCTION
• SOFTWARE TESTING
• PRODUCT RELEASE AND MAINTENANCE

2
SOFTWARE LIFE CYCLE
MANAGEMENT

3
1.1 Introduction

• Robots do not make mistakes, there will be no defects in design and construction.
• Software requirements -> converted to Software design -> Software construction etc
• Using any software Engineering framework, it is possible to design and construct industry
strength software products that gives good quality

1.2 Software Engineering Management:

• Software Engineering has two parts
• Software Engineering Management
• Software Technical Engineering

1.3 Software Life-cycle Management process:

• Customer requirements are gathered and developed, and then an appropriate software
design is made that fulfills the needs of these requirements by converting these
requirements into a suitable software design.

4
5
1.4 Software Life-cycle Management process:
• Customer requirements are gathered and developed, and then an appropriate software
design is made that fulfills the needs of these requirements by converting these
requirements into a suitable software design.

1.4.1 Software Life cycle in Waterfall Model:

• The waterfall model is best suited for large software development projects for government,
military, and other industries only when SRS is well defined.

1.4.2 Software Life cycle in Iterative Model:

• We can take a few of the requirements and start designing and then building the software
only for this set of requirements. Once the software is built, it is delivered to the end users.
• So the cycle for all these activi­ties may last a few weeks (1–6 weeks).
• Some methodologies scrum, Extreme Programming.

1.4.3 Software Life cycle in Concurrent Engineering Model:

• If tasks involved in these phases can be broken into smaller parts and if many teams can
be employed to do these tasks

6
7
1.5 Software life cycle process:
1.5.1 Software requirements:
• Statement of work (SOW) is signed
• Requirements gathering template be used.
1.5.2 Software Design
• Check with Functional and nonfunctional requirements
1.5.3 Software Build
• Software Coding
• Rework has to checked
1.5.4 Software Testing
• Fixing bugs and testing
1.5.5 Software Release
• Phases : alpha (Internal Users- Not to Customers), Beta( free for Public and Customers to
find balance bugs and for removal) and final ( Without any bugs – fully tested Product).
1.5.6 Software Maintenance
Software code is not readable, Design and construction documents are either outdated,
nonexistent, or insufficient

8
1.6 Software life-cycle metrics
• SRS Document for all process till end. Measure the productivity.
1.7 Work Products
• Work-In-Process(WIP)
• Requirement Specification Document,Product Model,Untested Product, Tested Product,
User Accepted Product.+User Mannuals.
1.8 Quality assurance
• After each phase of software development gets completed, there should be exit criteria that
will ensure that all work has finished per project plan and that these work products are
defect free.
• The exit criteria should include completion of all processes for the phase, completion of
work products, and finally acceptable quality of work prod­ucts.
• For quality control, formal review processes should be included in each phase.

9
SOFTWARE REQUIREMENTS
MANAGEMENT

10
1.1 Introduction

• Requirements are one of the most important parts of the software project.
• Requirements for internal software projects come with fewer details.
1.2 Software Requirements Developments
• Requirements can be grouped into two categories:
• Functional requirements
• Non - Functional requirements

11
Limitations and constraints
• Cost and cost drivers
• Risks associated with requirements
• Time constraints and schedule drivers

12
1.2.1 Develop Requirements
• The initial requirements, whether from customers or from other sources, need to be made
usable as input for making software requirements.
1.2.2 Requirements Development tasks
• Some of the tasks done during requirement development include:
• Customer requirements are refined.
• Establish and maintain product
• Allocate the requirements
• Identify interface requirements
1.3 Software Requirements Management
• A very good requirement change management and version control is definitely necessary for
a successful software development project.
1.3.1 Requirements change control
• Whenever requirements are changed, there must be a system that will notify each person
whose work is affected due to change in requirement.
• How the change will impact their work also must be assessed.
• One more aspect of requirement change is the severe impact it has when the development and
testing are being carried out by distributed teams.

13
1.3.2 Requirements Problem Diagnosis
• When distributed teams are working on a project, the best option is that requirements
are kept in a central repository with access permissions to all project teams.
• People with less experience should be identified, and care should be taken that they
understand these changes and do their work accordingly.
1.4 Requirements life cycle
In Waterfall Model
• Each phases commences once the previous phase gets over.
• So, one iteration in each phase.
In Iterative Model
• In Scrum, the list of requirements is kept in a repository, which is known as the “backlog.”
• In agile models like Scrum(Management and Productivity) and eXtreme Programming
(Software Quality and Engineering Techniques).
1.5 Software Practical strategy
• Requirements come in many forms (e-mail, chats, customer request, meetings, reviews,
etc.).
• Requirements should be verified with the source
• Requirements should be complete.

14
1.6 Software Requirements Artifacts
• Software requirement specifica­tions document (SRS document) must contain specifications
in the most structured form.
• Verification and Validation document for the SRS document is the artifact of this phase.

1.7 Software Requirements quality control

• Software requirements can be checked or tested for defects. Found defects can subsequently
be removed, and, thus, quality of the software requirements can be improved.

15
SOFTWARE DESIGN MANAGEMENT

16
• Software design development can be likened to designing a physical product. Suppose a
new car model is to be developed. The car design is broken down into separate components
and in the end assembling them will become a complete design for the car model.
• Suppose one factor to be considered is that during a car accident, the car body should take
most of the impact and the passengers should get the least impact, so that injury to car
passengers can be minimized during accidents.
3.1 Software Design Fundamentals
• When a building is constructed, a good foundation is laid out for the building, so that the
building will have a long lifespan and will not collapse.
• Similarly, it is given a strong and resil­ient structure, so that even in case of an earthquake, it
will not fall down.

17
3.1.1 Design Types
• Work products grouped together to form software design
3.1.2 Design standards
• If design standards are implemented on a project, then it will help in streamlining activi­ties
that are involved during the software design phase.
3.1.3 Design Activities
• Software design activities produce many intermediate documents and work products
3.2 Software Design Methods
3.2.1 Top Down Approach
- In the top-down approach, the top structure of the product is conceived and designed first.
Once the structure is perfected, components that will make the product are designed.
- - A top-down approach also helps in creating reusable components and hence increases
productivity as well as maintainability.
3.2.2 Bottom-up Approach
• - In the bottom-up approach, first, the minute functions of the software product are struc­
tured and designed. Then, the middle-level components are designed, and, finally, the top-
level structure is designed.
• - There are some benefits to the bottom-up approach. It leads to incremental
building of design that ensures that any missing information can be accommodated later in
the design

18
3.3 Design version control
• In product development for a software vendor, many versions of the same product have to
be developed for fulfilling different customers.
3.3.1 subversions
• During the software development life cycle, the design changes with changes in
requirement speci­fications or when it is felt to change design as it no longer supports
additional requirements.
3.4 Design characteristics
• Modular
• Simple
• Maintainable
• Verifiable
• Portable

19
3.5 Software Design Techniques
• Software design is the phase when a short sighted or myopic vision can turn the software
product development into a nightmarish affair for downstream phases.
3.5.1 Prototypes
• Prototyping is cheap and fast. It also gets a buy in from customer at an early stage of the
project. If not a full prototype of the application, a partial prototype can help you win over
your customer.
3.5.2 Structural Models
• Many classes together build a com­ponent. Components in turn make modules. Modules in
turn make the complete application.
• Breaking into parts for an application can best be done using a structural analysis.
3.5.3 Object-Oriented Design
• It has always been difficult to represent business entities and business information flow in a
soft­ware model.
3.5.4 System Analysis
• System analysis is the process of finding solutions in the form of a system designed from the
inputs coming from business needs.

20
3.5.5 Entity Relationship Models
• Entity relationship models are one of the ways to represent business entities and their
relationships to each other through diagrams.
3.5.6 Design Reuse
• For large software products, the design can be broken into many design parts representing
each module of the product.
3.6 Software Design for Internet
• Some of the characteristics that impact their design include:
• They are used by a large number of people. So they need to have good performance built
into design
• They are information providers with lots of content.
• They are asynchronous.
• They are stateless.
3.7 Software Design Quality
• Quality in the design of the software application can be built by adhering to best practices
(soft­ware engineering principles) in processes adopted for the design as well as making
sure that requirements have been converted into good design.

21
3.8 Concurrent Engineering in SD
• Concurrent engineering deals with taking advance information from an earlier stage for a
later stage in project, so that both the stages can be performed simultaneously.

3.9 Module Division(refactoring)

• To change the internal structure of software code without changing external behavior of the
software product. To do this, one technique is employed, which is known as refactoring.
• Refactoring can be achieved by dividing cumbersome classes into smaller classes that can
be managed and used in a better way.

3.10 Module coupling

• Changes in code result in more than normal occurrence of defects as dependency between
modules keeps increasing with increase in the size of the product.

22
SOFTWARE CONSTRUCTION

23
• Construction is one of the most labor intensive phases in the software development life
cycle. It comprises 30% or more of the total effort in software development.
• Due to the labor intensive nature of the software construction phase, the work is divided
not only among developers, but also small teams are formed to work on parts of the
software build.
4.1 Coding Standards
• Developers are given software design specifications in the form of use cases, flow diagrams,
UI mock ups, etc., and they are supposed to write a code so that the built software matches
these speci­fications.
4.1.1 Modularity
• The produced software code should be modular in nature.
4.1.2 Clarity
• The produced code should be clear for any person who would read the source code.
4.1.3 Simplicity
• The source code should have simplicity and no unnecessary complex logic; improvisation
should be involved, if the same functionality can be achieved by a simpler piece of source
code.

24
4.1.4 Reliability
• Reliability is one of the most important aspects of industry strength software products.
• Reliability of source code can be increased by sticking to the standard processes for
software construction.
4.1.5 Safety
• Industries like medicine and healthcare, road safety, hazardous material handling need
foolproof software products to ensure that either human lives are saved (in case of medicine
and healthcare) or human lives are not in danger.

4.1.6 Maintainability
• As has been pointed out after several studies, maintenance costs are more than 70% of all
costs including software development, implementation, and maintenance

4.2 Coding Framework

For software construction, you need to have a coding framework that will ensure a consistent
coding production with standard code that will be easy to debug and test.

25
4.3 Reviews (Quality Control)
• It is estimated that almost 70% of software defects arise from faulty software code.
• To com­pound this problem, software construction is the most labor intensive phase in
software devel­opment.

4.3.1 DeskChecks (Peer Reviews)

• Deskchecks are employed when a complete review of the source code is not important.
• The developer sends his piece of code to the designated team members.

4.3.2 Walkthroughs
• Walkthroughs are formal code reviews initiated by the developer.

4.3.3 Code Reviews

• Code reviews are one of the most formal methods of reviews.

4.3.4 Inspections
• Code inspections are final reviews of software code in which it is decided whether to pass a
piece of code for inclusion into the main software build.

26
4.4 Coding Methods
• Converting design into optimal software construction is a very serious topic that has
generated tremendous interest over the years.

4.4.1 Structured Programming

• Structured programming evolved after mainframe computers became popular.
• Using structured programming, large programs could be constructed that could be used for
making large commercial and business applications.

4.4.2 Object-Oriented Programming

• In structured programming, data and structured code are separate and accordingly are
modeled separately.

4.4.3 Automatic Code Generation

• Some CASE and modeling tools are available that generate software code.

4.4.4 Software Code Reuse

• Many techniques have evolved to reduce the labor intensive nature of writing source code.
• Software code reuse is one such technique.

4.4.5 Test-Driven Development

• This concept is used with iteration-based projects especially with eXtreme Programming
tech­nique.

27
4.4.6 Pair Programming
• Pair programming is a quality driven development technique employed in the eXtreme
Programming development model.
4.5 Configuration Management
• Configuration management plays an important role in the construction phase.
• Due to changes in requirements and design, an already developed source code needs to be
changed. So it happens that the development team ends up with many versions of a source
code during the project.
4.6 Unit testing
• Whenever a developer writes a piece of code, he feels confident that he has written a clean
code and that it does not need testing.
4.7 Integration testing
Most software development is done after partitioning the software application under develop­
ment first and then allocating it to distributed teams
4.8 Iterative Model
Iterative development is definitely a good approach, as it provides an opportunity to spread
the risk over many iterations and thus helps in stopping any catastrophe to occur.

28