SOFTWARE LIFE CYCLE MANAGEMENT

9.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.
9.2 Software Engineering Management:

 Software Engineering has two parts

o Software Engineering Management
o Software Technical Engineering

9.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.

9.3.1 Software Life cycle in Waterfall Model:

 The waterfall model is best suited for projects where well-developed software requirement
specifications (SRSs) exist.
 The waterfall model is best suited for large software development projects for government,
military, and other industries only when SRS is well defined.
9.3.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 activities may last a few weeks (1–6 weeks).
 This cycle is repeated until all requirements are converted into the software product. In this way,
the huge risk of delivering wrong software product at the end of a long period of development can
be avoided.
 Some well-known methodologies include Scrum, EXtreme Programming, incremental iteration
model, and spiral development.
 There is one more iteration-based model, which was developed by Rational Corporation (part of
IBM). It is known as the rational unified process model.

9.3.2 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

9.3.3 Software life cycle process:

 To test these parts, dummy parts are used for these interfaces so that the part can be tested (also
known as test oracles). Once these parts are developed by each independent team, they are
integrated to make the complete software product.

9.3.3.1 Software requirements:

 Statement of work (SOW) is signed – consulted with the customer
 Software used for management process
 Requirements gathering template be used.
 Some of them include the iterative model, agile methods, spiral method, and extreme
programming in order to avoid the risk to adapt the new changes in requirement

9.3.3.2 Software design

 Design also considers factors such as reliability, robustness, security, ease of use,
internationalization, localization, and compatibility. All of these are collectively termed as
nonfunctional design requirements.
 Some of the challenges in software design include difficulty in modeling due to changes or
unclear requirements, limitations of representation of requirements into system design, etc.

9.3.3.3 Software build

 Software coding (also known as building or construction) is the most labor-intensive task in
software development projects. – standard codes to be used
 Some of the challenges in software construction include lack of team work, rework due to
changes in design, lack of clarity in design, bad allocation of work, and bad component
structure
 In waterfall and agile model, rework should be avoided

9.3.3.4 Software testing

- fixing bugs

- Integration, unit, system testing etc

- we can have a schedule of 15 days to test the application and acceptable quality level of 100 critical
bugs to be fixed after the system goes live.

9.3.3.5 Software Release

- alpha phase -> software released to internal users

- beta phase -> software released to customers

- final phase

9.3.3.6 Software Maintenance

Some of the issues that arise in software maintenance include

 Software code is not readable

 Design and construction documents are either outdated, nonexistent, or insufficient
 Unstructured code
 Maintenance personnel having insufficient knowledge of the software application

9.4 Software Life-cycle metrics

- SRS document

9.5 Work Products

 - Work in Process(WIP)

9.6 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 products. For quality control, formal review
processes should be included in each phase.
 If any of the three exit criteria is not met, rework may be needed, and, thus, instead of the
project moving forward, it will move back

SOFTWARE REQUIREMENTS MANAGEMENT:

1. Introduction
 Requirements are one of the most important parts of the software project.
 Requirements for internal software projects come with fewer details.
 In the case of commercial and business software development for external customers, the details
of requirements can vary.
 But in case of offshore outsourced projects, complete requirement details are needed and hence
are provided by customers.
2. Software Requirements Development:
 Consider this request from the marketing department of a software vendor: “We need to
develop an online access system for our banking application by next month.” Yes, this is a
requirement with the timeline from the marketing department’s point of view.
 Developing the requirement is done by software engineering folks.
 Some of the requirements may not be feasible. In those cases, some alternative solution has to
be suggested to the customer and approval obtained from him.
 Once most of the requirements are made clear and approved, then software design processes
can begin.

Requirements can be grouped into two categories:

a. Functional requirements
b. Non - Functional requirements
  Some of the nonfunctional requirements include security, performance, usability,
compatibility, etc.
 Some of the considerations associated with requirement development
o Well-defined required functionality
o Defined details of the operational environment
o Maintenance and final retirement plan should be in place
 Limitations and constraints to be considered for developing the software product
o Cost and cost drivers
o Risks associated with requirements
o Time constraints and schedule drivers
 All the requirements need to be converted into software features (logical entities)

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.
 Any irrelevant information from the gathered information must be purged.

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
 The requirements are analyzed and validated
 Establish and maintain operational concepts
 Establish and maintain a definition
 Analyze requirements
  Validate requirements
2.3 Software Requirements Management
 A very good requirement change management and version control is definitely necessary
for a successful software development project.
 When analyzed, most failed software projects reveal that the failure was due to unclear
requirements or too many requirement changes.
2.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.
 With a distributed team scenario, communicating the change request immediately
and effectively so that rework can be avoided is a big challenge.
 One more issue with requirement changes pertain to version control. It is difficult to
know whether all distributed teams are working on the correct version of the
requirements or not.
2.3.2 Requirement Problems 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.
 Requirement allocation should be done in such a way that each team and their
individual members are always aware of what requirement they are working
against, and where on the configuration management server the relevant work
products are located.
2.4 Requirements Life cycle:
 In Waterfall Model
 Each phases commences once the previous phase gets over
 So, one iteration in each phase.
 Modified version of waterfall Model used in most of the
organizations.
 Rework done, if the requirements are not met or if defects occurred.
  Iterative Model
o Iterative models (including eXtreme Programming, agile methodology, and
Scrum), complete requirements may be gathered but not used for product
development.
o In Scrum, the list of requirements is kept in a repository, which is known as
the “backlog.”
o In agile models like Scrum and eXtreme Programming, the sources of
requirements are the customers, customer feedback after iteration
completion.

2.5 Software Requirements Practical strategy:

1. Requirements come in many forms (e-mail, chats, customer request, meetings, reviews, etc.).
2. Requirements should be verified with the source
3. Requirements should be complete,
4. Requirements should be prioritized based on urgency, ROI, etc
 5. Trace dependency among requirements so that if one requirement is important but is depen-
dent on another requirement that is not a priority
6. Track requirement changes.

Example: Sales department, Desktop system.

2.6 Software Requirements Artifacts:

 Software requirement specifications 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.
2.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.

3. Software Design Management

 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
 For this to happen, the car body should be made of material that can collapse on impact and thus take
most of the impact. So during design, when selecting the material of the car with safety in mind, the
body is one of the prime considerations.
 Software design is done using modeling languages like UML and using notation methods like use cases
and activity diagrams.

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 resilient structure, so that even in case of an earthquake, it will not
fall down.
 The design should provide a sound, resilient, and scalable structure to support the software system.
 To deal with this problem, a technique called refactoring is used on these agile projects where
incremental software development is done.
 The current trend of service-oriented architecture (SOA) has also helped tremendously in changing
the design concepts.
3.1.1 Design Types
- Work products grouped together to form software design
- Some examples include prototypes, structural models, object-oriented design, systems analysis, and
entity relationship models.

3.1.2 Design standards

 If design standards are implemented on a project, then it will help in streamlining activities that are
involved during the software design phase.
 Some industry standards for software design include operator interface standards, test scenarios,
safety standards, design constraints, and design tolerances.

3.1.3 Design Activities

 Software design activities produce many intermediate documents and work products. These include
product architecture description, allocated requirements, product component descriptions, product-
related life-cycle process descriptions, key product characteristic descriptions, required physical
characteristics and constraints, interface requirements

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.

- Functional consideration taken care for making the structure.

- Non Functional aspects are taken care at the beginning of design.

- A top-down approach also helps in creating reusable components and hence increases productivity
as well as maintainability.

- Drawback of the top-down approach is that it is a risky model. The whole design has to be made in
one go instead of making attempts to incrementally building the design, which is relatively a safer option.
3.2.2 Bottom-up Approach
- In the bottom-up approach, first, the minute functions of the software product are structured 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

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.
 At the top level of the hierarchy of files on the configuration and version control tool, the directory
name should be the project/product name.

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.
 In such cases, the main design is changed to meet new conditions. However, the main design version
is also kept. The new design is saved as a separate file. So, we have design two documents now.

3.4 Design characteristics

- Modular

- Simple
 - Maintainable

- Verifiable

- Portable

- Reliable

- Secure

- Scalable

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.
 A good software design not only ensures a smooth transition to the development phase but also
ensures that the software product has a good shelf life during operation.
 Starting with the early procedural programming paradigms, programming has evolved into present
day “service-oriented architecture.”

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.
 A miscommunication or misunderstanding between the customer and the project team gets cleared
once the differences of opinion are sorted out early on during the prototype demonstration sessions.
 In any case, customers do not care about internal workings of the application.
 Customer expectations become difficult to manage in such instances. Prototypes can only show the
user interface screens.

3.5.2 Structural models

 At the bottom are the smallest units of functions and procedures in a software application.
 Many classes together build a component. 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.
  This feature set is analyzed and broken down into smaller sets of features, which will go into different
modules.

3.5.3 Object-Oriented Design

 It has always been difficult to represent business entities and business information flow in a software
model.
 Business entities are represented as objects in the object-oriented software design.

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.
 For instance, a person may want to access his bank account using an Internet connection to the online
Web site of the bank. This scenario calls for many things that are involved in the whole chain of objects
and events.
 Based on the analysis, a system model can be made that will be used in developing the application.

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.
 With object-oriented modeling, it is possible to correlate each object with a corresponding database
object.

3.5.6 Design Reuse

 For large software products, the design can be broken into many design parts representing each
module of the product.
 If we can use a standard method of representing the same information for these components, then it
is possible to use these pieces of information in many components by reusing them.

3.6 Software Design for Internet

 Internet applications are inherently different. Thus, their design is also different from legacy
client/server applications.
 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.
 All transactions should be made stateless, so that if any transaction is in progress and the
connection between server and user machine breaks, the transaction is reverted back.

3.7 Software Design Quality

 Quality in the design of the software application can be built by adhering to best practices (software
engineering principles) in processes adopted for the design as well as making sure that requirements
have been converted into good design.
  The design should avoid complexity, inconsistency, and inefficiency.
 Inconsistency issues can be addressed by having a solid architecture on which units and other program
units should be based.
 Quality control for software designs can be done by checking the design after it is built for defects.

3.8 Concurrent Engineering in Software Design

 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.
 Until all details about design are made, you cannot start development. So, the development team
cannot start their job until they have a software design in their hands.

3.9 Module Division (Refactoring)

 Whenever a software product is designed, it is done with good intentions.

 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.
 When software code starts having these characteristics, then it is better to go for code cleaning or
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.
 To reduce the chances of product defects, it is necessary to reduce the number of calls among
different modules and classes.

4. SOFTWARE CONSTRUCTION
 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.
  The advantage to this is that these project teams do the software coding and other construction
work in parallel with each other and thus the construction phase can be collapsed.
 The whole process of construction should follow a proven process so that the produced code is
maintainable, testable, and reliable.

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
specifications.
 At any time, a code written by a developer will always be different from that written by any other
developer.

4.1.1 Modularity
 The produced software code should be modular in nature.
 Each time a particular functionality is needed in the software construction, it can be implemented
using that particular module of software code.

4.1.2 Clarity
 The produced code should be clear for any person who would read the source code.
 There should be sufficient documentation inside the code block, so that anybody reading the code
could understand what a piece of code is supposed to do.

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.
 For instance, in the case of object-oriented programming, abstraction and information hiding add
a great degree of simplicity.

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.
 If the development team feels that this is the case, then it is far better to restructure the software
design and then write a code based on the new structure than to add a spaghetti code on top of a
crumbling structure.

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. Here the software code must have inbuilt safety
harnesses.

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.
 In general, coding frameworks allow construction of the common infrastructure of basic
functionality which can be extended later by the developers.

4.3 Reviews (Quality Control)

 It is estimated that almost 70% of software defects arise from faulty software code.
 To compound this problem, software construction is the most labor intensive phase in software
development.
 If those defects are allowed to go in software testing (which is the next phase), then fixing those
defects will become costlier
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.
 The developer reads those feedbacks and may decide to incorporate or to discard those sug-
gestions.

4.3.2 Walkthroughs

 Walkthroughs are formal code reviews initiated by the developer.

 At the meeting, the developer presents his method of coding and walks through his piece of code.

4.3.3 Code Reviews

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

 At the meeting, team members review the code and point out any code errors, defects, or
improper code logic for likely defects.

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.

4.4 Coding Methods

 Converting design into optimal software construction is a very serious topic that has generated
tremendous interest over the years.
 Software product size affects the methods that can be used to construct specific sized software
products. Advancement in the field of computer science also allows discovery of better
construction methods.

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.
 Structured programming enabled programmers to store large pieces of code inside procedures
and functions.

4.4.2 Object-Oriented Programming

 In structured programming, data and structured code are separate and accordingly are modeled
separately.
 Widely used as an example in object-oriented programming books, a car consists of a chassis, an
engine, four wheels, body, and transmission.
 When a software system is modeled to represent real-world objects, both data and structure are
taken care of in object-oriented programming.

4.4.3 Automatic Code Generation

 Some CASE and modeling tools are available that generate software code.
  The generated code is specific to the platform and runs on the device (hardware and software
environment) for which the code is generated.

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.
 Code reuse in procedural programming techniques is achieved by creating special functions and
utility libraries and using them in the source code.

4.4.5 Test-Driven Development

 This concept is used with iteration-based projects especially with eXtreme Programming tech-
nique.
 Before developers start writing source code, they create test cases and run the tests to see if they
run properly and their logic is working.

4.4.6 Pair Programming

 Pair programming is a quality driven development technique employed in the eXtreme

Programming development model.
 While one developer writes the code, the other developer sits behind him and guides him through
the requirements (functional, nonfunctional).

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.
 There is one more dimension to configuration management for the construction phase.
 During construction, many software builds are maintained for different versions of the product
being developed.
 These builds can break if a bad piece of code is checked into the build by any developer.
 When the build is broken, then no other developer can check in his code.
 If the smoke test fails, that means the build has failed and thus the automated system can e-mail
the build information to concerned people.
 If the build fails, then the developer who had checked-in in the code gets the message and
immediately tries to fix the build.
 Once the build is fixed, then other developers can check-in their code.
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.
 For unit testing, generally developers are comfortable as long as there are no changes required
(due to change in design or requirements) in their code.
 But once some change takes place in the code somewhere, other things change.
 Generally, it is one of the most challenging situations in software construction to find the impact
of change on other parts of the product under development.

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.
 Generally, modules of code are developed first. Later, they need to be integrated with each other
to make a complete software application.
 Integration testing has been becoming more and more important, as most software being
developed is modular in nature.

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.
 The main bug bear of software construction is complexity.
 Using techniques like pair programming, test-driven development, continuous integration, formal
reviews, etc., ensures that good quality is achieved from the very beginning of construction and
keep the same level of quality throughout the development process.