SOFTWARE

ENGINEERING
 COURSE OUTCOME

 CO1 Select appropriate Software Development Lifecycle Model for a given

requirement.
 CO2 Comprehend various Functional and Non-Functional Requirements.
 CO3 Create User Interface using Design concepts.
 CO4 Generate Test cases for the developed Code.
 CO5 Estimate Cost & Maintenance of the Project.
 CO6 Generate an overall plan for a specific application development.

2
 UNIT 1
Evolving Role of Software

Software Evolution
The process of developing a software product using software engineering principles and methods is referred to as
software evolution.

Steps:
 Evolution starts from the requirement gathering process.

 After which developers create a prototype of the intended software and show it to the users to get their
feedback at the early stage of software product development.

 The users suggest changes, on which several consecutive updates and maintenance keep on changing too.

 This process changes to the original software, till the desired software is accomplished.

 Even after the user has desired software in hand, the advancing technology and the changing requirements
force the software product to change accordingly.

3
 Re-creating software from scratch and to go one-on-one with requirement is not
feasible.

 The only feasible and economical solution is to update the existing software so that
it matches the latest requirements.

4
 Software Evolution Laws

Lehman has given laws for software evolution. He divided the software into three different categories:

S-type (static-type)
 This is a software, which works strictly according to defined specifications and solutions.

 The solution and the method to achieve it, both are immediately understood before coding.

 The s-type software is least subjected to changes hence this is the simplest of all. For example,
calculator program for mathematical computation.

P-type (practical-type)
 This is a software with a collection of procedures. This is defined by exactly what procedures can do.

 In this software, the specifications can be described but the solution is not obvious instantly. For
example, gaming software

5
E-type (embedded-type)
 This software works closely as the requirement of real-world environment.
 This software has a high degree of evolution as there are various changes in laws, taxes etc. in the real
world situations.
 For example, Online trading software

Lehman has given eight laws for E-Type software evolution :

 Continuing change - An E-type software system must continue to adapt to the real world changes,
else it becomes progressively less useful.

 Increasing complexity - As an E-type software system evolves, its complexity tends to increase
unless work is done to maintain or reduce it.

 Conservation of familiarity - The familiarity with the software or the knowledge about how it was
developed, why was it developed in that particular manner etc. must be retained at any cost, to
implement the changes in the system
.
 Continuing growth- In order for an E-type system intended to resolve some business problem, its
size of implementing the changes grows according to the lifestyle changes of the business.

6
 Reducing quality - An E-type software system declines in quality unless
rigorously maintained and adapted to a changing operational environment.

 Feedback systems- The E-type software systems constitute multi-loop, multi-level

feedback systems and must be treated as such to be successfully modified or
improved.

 Self-regulation - E-type system evolution processes are self-regulating with the

distribution of product and process measures close to normal.

 Organizational stability - The average effective global activity rate in an evolving

E-type system is invariant over the lifetime of the product.

7
Software Paradigms
 Software paradigms refer to the methods and steps, which are taken while designing the software

Software Development Paradigm

This Paradigm is known as software engineering paradigms where all the engineering concepts pertaining to the development of
software are applied.

It consists of
 Requirement gathering
 Software design
 Programming

Software Design Paradigm

This paradigm is a part of Software Development and includes –
 Design
 Maintenance
 Programming

Programming Paradigm
This paradigm is related closely to programming aspect of software development. This includes
 Coding
 Testing
 Integration

8
 Need of Software Engineering

The need of software engineering arises because of higher rate of change in user requirements and environment
on which the software is working.

 Large software - It is easier to build a wall than to a house or building, likewise, as the size of software
become large engineering has to step to give it a scientific process.

 Scalability- If the software process were not based on scientific and engineering concepts, it would be easier
to re-create new software than to scale an existing one.

 Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of
computer and electronic hardware. But the cost of software remains high if proper process is not adapted.

 Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which user works. If the nature of software is always changing, new enhancements need to
be done in the existing one. This is where software engineering plays a good role.

 Quality Management- Better process of software development provides better and quality software product.

9
 Characteristics of good software

A software product can be judged by what it offers and how well it can be used. This software
must satisfy on the following grounds:
 Operational

 Transitional

 Maintenance

Operational
This tells us how well software works in operations. It can be measured on:
 Budget

 Usability

 Efficiency etc..

10
Transitional
This aspect is important when the software is moved from one platform to another:
 Portability

 Interoperability

 Reusability

 Adaptability

Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the ever-
changing environment:
 Modularity

 Maintainability

 Flexibility

 Scalability

11
 Definition-Software Engineering

 Software is more than just a program code. A program is an executable code, which serves some computational
purpose. Software is considered to be collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is called software product.

 Engineering on the other hand, is all about developing products, using well-defined, scientific principles and
methods

 Software engineering is an engineering branch associated with development of software product using well-
defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and
reliable software product.

OR

 Software engineering is a branch of computer science, which uses well-defined engineering concepts required to
produce efficient, durable, scalable, in-budget and on-time software products

12
 Life Cycle Models

Software Development Lifecycle (Sdlc)

 It is a systematic process for building software that ensures the quality and correctness

of the software built.

 SDLC process aims to produce high-quality software that meets customer expectations.

 The system development should be complete in the pre-defined time frame and cost.

 SDLC consists of a detailed plan which explains how to plan, build, and maintain
specific software.

 Every phase of the SDLC life cycle has its own process and deliverables that feed into
the next phase.

13
 Need of SDLC

 It offers a basis for project planning, scheduling, and estimating

 Provides a framework for a standard set of activities and deliverables

 It is a mechanism for project tracking and control

 Increases visibility of project planning to all involved stakeholders of the development

process

 Increased and enhance development speed

 Improved client relations

 Helps you to decrease project risk and project management plan overhead

14
 SDLC Phases
The entire SDLC process divided into the following stages:

15
 Phase 1: Requirement collection and analysis:

 The requirement is the first stage in the SDLC process.

 It is conducted by the senior team members with inputs from all the stakeholders and
domain experts in the industry.

 Planning for the quality assurance requirements and recognization of the risks involved
is also done at this stage.

 This stage gives a clearer picture of the scope of the entire project and the anticipated
issues, opportunities, and directives which triggered the project.

 Requirements Gathering stage need teams to get detailed and precise requirements. This
helps companies to finalize the necessary timeline to finish the work of that system.

16
 Phase 2: Feasibility study
 Once the requirement analysis phase is completed the next step is to define and
document software needs.
 This process conducted with the help of 'Software Requirement Specification'

document also known as 'SRS' document.

 It includes everything which should be designed and developed during the project life

cycle.
There are mainly five types of feasibilities checks:
 Economic: Can we complete the project within the budget or not?

 Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
 Operation feasibility: Can we create operations which is expected by the client?

 Technical: Need to check whether the current computer system can support the

software
 Schedule: Decide that the project can be completed within the given schedule or not.

17
 Phase 3: Design
 In this third phase, the system and software design documents are prepared as per
the requirement specification document. This helps define overall system
architecture.
 This design phase serves as input for the next phase of the model.
 There are two kinds of design documents developed in this phase

High-Level Design (HLD)

 Brief description and name of each module

 An outline about the functionality of every module

 Interface relationship and dependencies between modules

 Database tables identified along with their key elements

 Complete architecture diagrams along with technology details

18
Low-Level Design(LLD)
 Functional logic of the modules

 Database tables, which include type and size

 Complete detail of the interface

 Addresses all types of dependency issues

 Listing of error messages

 Complete input and outputs for every module

19
 Phase 4: Coding
 Once the system design phase is over, the next phase is coding.

 In this phase, developers start build the entire system by writing code using the
chosen programming language.

 In the coding phase, tasks are divided into units or modules and assigned to the
various developers.

 It is the longest phase of the Software Development Life Cycle process.

 In this phase, Developer needs to follow certain predefined coding guidelines.

 They also need to use programming tools like compiler, interpreters, debugger to
generate and implement the code.

20
 Phase 5: Testing

 Once the software is complete, and it is deployed in the testing environment.

 The testing team starts testing the functionality of the entire system. This is done
to verify that the entire application works according to the customer requirement.

 During this phase, QA and testing team may find some bugs/defects which they
communicate to developers.

 The development team fixes the bug and send back to QA for a re-test.

 This process continues until the software is bug-free, stable, and working
according to the business needs of that system.

21
 Phase 6: Installation/Deployment &Phase 7 Maintenance:

 Once the software testing phase is over and no bugs or errors left in the system then the final
deployment process starts.

 Based on the feedback given by the project manager, the final software is released and checked
for deployment issues if any.
Phase 7: Maintenance
Once the system is deployed, and customers start using the developed system, following 3 activities
occur

 Bug fixing - bugs are reported because of some scenarios which are not tested at all
 Upgrade - Upgrading the application to the newer versions of the Software
 Enhancement Adding some new features into the existing software

The main focus of this SDLC phase is to ensure that needs continue to be met and that the system
continues to perform as per the specification mentioned in the first phase.

22
 Waterfall model
 The waterfall is a widely accepted SDLC model.
 In this approach, the whole process of the software development is divided into
various phases.
 In this SDLC model, the outcome of one phase acts as the input for the next phase.
 This SDLC model is documentation-intensive, with earlier phases documenting
what need be performed in the subsequent phases.

23
 Phases

 Requirement Gathering stage:

During this phase, detailed requirements of the software system to be developed are gathered from client
 Design stage
Plan the programming language or database or high level technical details of the project
 Build stage
It is nothing but coding the software
 Test Stage
In this phase you test the software to verify that is built as per specifications given by client
 Deployment stage
Deploy the applications in the respective environment
 Maintenance stage
Once your system is ready to use, you may later require change the code as per customers request

24
Waterfall model can be used when
 Requirements are not changing frequently

 Application is not complicated and big

 Project is short

 Requirement is clear

 Environment is stable

 Technology and tools used are not dynamic and is stable

 Resources are available and trained

25
26
 Incremental Approach

 The incremental model is not a separate model. It is essentially a series of waterfall cycles.

 The requirements are divided into groups at the start of the project. For each group, the
SDLC model is followed to develop software.

 The SDLC process is repeated, with each release adding more functionality until all
requirements are met.

 In this method, every cycle act as the maintenance phase for the previous software release.

 Modification to the incremental model allows development cycles to overlap.

 After that subsequent cycle may begin before the previous cycle is complete

27
Architecture

28
 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.

29
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

30
31
Incremental models are used when

 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

32
33
An Example of the Incremental Model:

As you can see in the above example, the core product is a cricket game where only two important players and
one umpire is present in the match.

34
 In the next increment, fielders are also added in the game, and thus the increases go on with new features
being added with every increment.

35
S.No WATERFALL MODEL INCREMENTAL MODEL
1 Need of Detailed Documentation Need of Detailed Documentation in incremental
in waterfall model is Necessary. model is Necessary but not too much.
2 In waterfall model early stage In incremental model early stage planning is also
planning is necessary. necessary.
3 There is high amount risk in
There is low amount risk in incremental model.
waterfall model.
4 There is long waiting time for
There is short waiting time for running software
running software in waterfall
in incremental model.
model.
5 Waterfall model can’t handle large
Incremental model also can’t handle large project.
project.
6 Flexibility to change in waterfall Flexibility to change in incremental model is
model is Difficult. Easy.

36
S.No WATERFALL MODEL INCREMENTAL MODEL
7 Returning to previous stage/phase in Returning to previous stage/phase in incremental
waterfall model is not possible. model is possible.
8 In waterfall model large team is required. In incremental model large team is not required.
9 In waterfall model overlapping of phases is In incremental model overlapping of phases is
not possible. possible.
10 There is multiple development cycles take place in
There is only one cycle in waterfall model.
incremental model

37
 Spiral Model

 The spiral model is a risk-driven process model.

 The spiral model is a combination of sequential and prototype models.

 This model is best used for large projects which involve continuous enhancements.

 There are specific activities that are done in one iteration (spiral) where the output is a small
prototype of the large software.

 The same activities are then repeated for all the spirals until the entire software is built.

38
39
40
41
 Pictorial Representation of SDLC Spiral Model

Different colors represent different spiral or iteration. For first iteration, represented in brown color , all the
4 activities (Planning, risk analysis, engineering and evaluation) are performed. After the evaluation phase is
over for the first iteration (spiral), second iteration (spiral) starts The second iteration, which is represented in
orange color, here again all the 4 activities (Planning, risk analysis, engineering and evaluation) are
performed. In a similar way, third iteration is done shown in blue color and so on the process continues

42
Use of Spiral Methodology:

 When project is large

 When releases are required to be frequent
 When creation of a prototype is applicable
 When risk and costs evaluation is important
 For medium to high-risk projects
 When requirements are unclear and complex
 When changes may require at any time
 When long term project commitment is not feasible due to changes in economic
priorities

43
44
 Software Prototyping Model

 Prototype Model is one of the most popularly used Software Development Life Cycle Models
(SDLC models).

 This model is used when the customers do not know the exact project requirements beforehand.

 In this model, a prototype of the end product is first developed, tested and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis
for developing the final product.

 In this process model, the system is partially implemented before or during the analysis phase
thereby giving the customers an opportunity to see the product early in the life cycle.

 In this process model, the system is partially implemented before or during the analysis phase
thereby giving the customers an opportunity to see the product early in the life cycle.

45
 The process starts by interviewing the customers and developing the incomplete high-level
paper model.

 This document is used to build the initial prototype supporting only the basic functionality as
desired by the customer.

 Once the customer figures out the problems, the prototype is further refined to eliminate them.

 The process continues till the user approves the prototype and finds the working model to be
satisfactory.

46
47
Phases of the Prototyping Model

The different phases are as follow:

Communication:
 This is the phase where the developer and Client set up the meeting and talk about the objectives that need
to be achieved for the software.

Design:
 The design has been done quickly as the requirements are cleared from both ends in providing and
receiving end. It is used to construct the prototype.
 It includes the important aspects of the software that is input and output but mainly focused on visible
aspects than planned activities.

Modeling:
 It provides a better idea of the requirement to develop the software and a better understanding of the
software product.

48
 Deployment:
 Before deployment, the client evaluates the software and if the client is not satisfied then it is refined
according to the client’s requirements.

 This process goes on until the point client requirements do not accomplish.

 After the client’s satisfaction with the product, the product finally deploys to the production environment.

 It is thoroughly evaluated and tested, and maintenance is done on a regular basis.

The prototype model mainly works at the high end in below format:

 Objectives determination.
 Develop the code.
 Communication and refine.
 Demonstrate.
 Test.
 Implement.

49
50
 Phases

Prototyping Model has following six SDLC phases as follow:

 Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the requirements of
the system are defined in detail. During the process, the users of the system are interviewed to
know what is their expectation from the system.

 Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple design
of the system is created. However, it is not a complete design. It gives a brief idea of the system
to the user. The quick design helps in developing the prototype.

 Step 3: Build a Prototype

In this phase, an actual prototype is designed based on the information gathered from
quick design. It is a small working model of the required system.

51
 Step 4: Initial user evaluation
In this stage, the proposed system is presented to the client for an initial evaluation. It
helps to find out the strength and weakness of the working model. Comment and suggestion are
collected from the customer and provided to the developer.

 Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the prototype according to
the user's feedback and suggestions.This phase will not over until all the requirements specified
by the user are met. Once the user is satisfied with the developed prototype, a final system is
developed based on the approved final prototype.

 Step 6: Implement Product and Maintain

Once the final system is developed based on the final prototype, it is thoroughly tested
and deployed to production. The system undergoes routine maintenance for minimizing
downtime and prevent large-scale failures.

52
 Types of Prototyping Models

Four types of Prototyping models are:

 Rapid Throwaway prototypes

 Evolutionary prototype

 Incremental prototype

 Extreme prototype

Rapid Throwaway Prototype

 Rapid throwaway is based on the preliminary requirement. It is quickly developed to show

how the requirement will look visually. The customer's feedback helps drives changes to
the requirement, and the prototype is again created until the requirement is baselined.

 In this method, a developed prototype will be discarded and will not be a part of the
ultimately accepted prototype. This technique is useful for exploring ideas and getting
instant feedback for customer requirements.

53
 Evolutionary Prototyping
 Here, the prototype developed is incrementally refined based on customer's feedback until it
is finally accepted.

 It helps you to save time as well as effort.

 That's because developing a prototype from scratch for every interaction of the process can
sometimes be very frustrating.

 This model is helpful for a project which uses a new technology that is not well understood.

 It is also used for a complex project where every functionality must be checked once.

 It is helpful when the requirement is not stable or not understood clearly at the initial stage.

54
 Incremental Prototyping:

 In incremental Prototyping, the final product is decimated into different small prototypes and developed
individually.

 Eventually, the different prototypes are merged into a single product.

 This method is helpful to reduce the feedback time between the user and the application development team.

Extreme Prototyping:

 Extreme prototyping method is mostly used for web development. It is consists of three sequential phases.

 Basic prototype with all the existing page is present in the HTML format.

 You can simulate data process using a prototype services layer.

 The services are implemented and integrated into the final prototype.

55
 Best practices of Prototyping
Here, are a few things which you should watch for during the prototyping process:

 You should use Prototyping when the requirements are unclear

 It is important to perform planned and controlled Prototyping.

 Regular meetings are vital to keep the project on time and avoid costly delays.

 The users and the designers should be aware of the prototyping issues and pitfalls.

 At a very early stage, you need to approve a prototype and only then allow the team to move to the next step.

 In software prototyping method, you should never be afraid to change earlier decisions if new ideas need to be
deployed.

 You should select the appropriate step size for each version.

 Implement important features early on so that if you run out of the time, you still have a worthwhile system

56
Paper Prototype:
A paper prototype is an example of a throwaway prototype created in the form of rough or hand-
sketched drawings of the product’s interface, front-end design, and sometimes the back end work

57
3D print:
 The latest technology has made it possible to print a 3d version of your product which can

actually work. But this technique is not feasible for mass production.

58
Digital Prototype
 A digital prototype allows product developers to create a virtual model of the product which

enables them to see how the individual components will work together and how the product
will look once it’s completed.
 That is, it lets the developers virtually explore the complete product before it’s actually built.

59
Scale Model
 The scale model is a smaller and a non-functional model commonly used for prototyping large

products like buildings, automobiles, etc.

60
 Advantages

Here, are important pros/benefits of using Prototyping models:

 Users are actively involved in development. Therefore, errors can be detected in the initial stage
of the software development process.

 Missing functionality can be identified, which helps to reduce the risk of failure as Prototyping
is also considered as a risk reduction activity.

 Helps team member to communicate effectively

 Customer satisfaction exists because the customer can feel the product at a very early stage.

 There will be hardly any chance of software rejection.

 Quicker user feedback helps you to achieve better software development solutions.

61
 Disadvantages

Here, are important cons/drawbacks of prototyping model:

 Prototyping is a slow and time taking process.

 The cost of developing a prototype is a total waste as the prototype is ultimately thrown away.
 Prototyping may encourage excessive change requests.
 Some times customers may not be willing to participate in the iteration cycle for the longer time
duration.
 There may be far too many variations in software requirements when each time the prototype is
evaluated by the customer.
 Poor documentation because the requirements of the customers are changing.
 It is very difficult for software developers to accommodate all the changes demanded by the clients.
 After seeing an early prototype model, the customers may think that the actual product will be
delivered to him soon.
 The client may lose interest in the final product when he or she is not happy with the initial
prototype.
 Developers who want to build prototypes quickly may end up building sub-standard development
solutions.

62
S.No. Spiral Model Prototype Model
1 Spiral model is a risk-driven software Prototype model is a software development model in
development model and is made with which a prototype is built, tested and then refined as
features of incremental, waterfall or per customer needs.
evolutionary prototyping models.
2 It is also referred to as meta mode It is also referred to as rapid or closed ended
prototype
3 It takes special care about risk analysis It does not give emphasis on risk analysis.
and alternative solution is undertaken
4 In spiral model, there is no continuous In prototype model, customer interaction is
customer interaction continuous until the final prototype is approved
5 It is best suited when the customer It is best suited when the requirement of the client is
requirements are clear. not clear and supposed to be changed

63
S.No Spiral Model Prototype Model
7 Cost effective quality improvement is Cost effective quality improvement is very
not possible. much possible
8 In Spiral model, improvement of quality In Prototype model, improvement of quality
can increase the cost of product. does not increases the cost of product

64
RAD Model

65
 Differences between Various Lifecycle Models

Properties of Water-Fall Incremental

Spiral Model Rad Model
Model Model Model
Planning in early
Yes Yes Yes No
stage
Returning to an
No Yes Yes Yes
earlier phase
Handle Large-
Not Appropriate Not Appropriate Appropriate Not Appropriate
Project
Detailed
Necessary Yes but not much Yes Limited
Documentation
Cost Low Low Expensive Low
Requirement Time boxed
Beginning Beginning Beginning
Specifications release

66
Properties of Water-Fall Incremental
Spiral Model Rad Model
Model Model Model
Flexibility to change Difficult Easy Easy Easy

User Involvement Only at beginning Intermediate High Only at the beginning

Maintenance Least Promotes Maintainability Typical Easily Maintained

Duration Long Very long Long Short

Risk Involvement High Low Medium to high risk Low

Framework Type Linear Linear + Iterative Linear + Iterative Linear

After completion of coding At the end of the

Testing After every iteration After completion of coding
phase engineering phase
Yes (As parallel
Overlapping Phases No No Yes
development is there)

Maintenance Least Maintainable Maintainable Yes Easily Maintainable

Re-usability Least possible To some extent To some extent Yes

67
Properties of Water-Fall Incremental
Spiral Model Rad Model
Model Model Model
Time-Frame Very Long Long Long Short
Working software At the end of the At the end of every At the end of every At the end of the
availability life-cycle iteration iteration life cycle
Objective High Assurance Rapid Development High Assurance Rapid development

Team size Large Team Not Large Team Large Team Small Team
Customer control
Very Low Yes Yes Yes
over administrator

68
 Unified Process (UP)
 The Unified Software Development Process or Unified Process is a popular iterative and
incremental software development process framework.

 The best-known and extensively documented refinement of the Unified Process is the
Rational Unified Process (RUP)

 The system is developed incrementally over time, iteration by iteration, and thus this approach
is also known as iterative and incremental software development.

 The iterations are spread over four phases where each phase consists of one or more iterations

69
Inception Phase

 The first and the shortest phase in the project.

 It is used to prepare basis for the project, including preparation of business case, establishing project
scope and setting boundaries, outlining key requirements, and possible architecture solution together
with design tradeoffs, identifying risks, and development of initial project plan—schedule with main
milestones and cost estimates.

 If the inception phase lasts for too long, it is like an indicator stating that the project vision and goals
are not clear to the stakeholders.

 With no clear goals and vision the project most likely is doomed to fail.

 At this scenario it is better to take a pause at the very beginning of the project to refine the vision and
goals.

 Otherwise it could lead to unnecessary make-overs and schedule delays in further phases

70
Elaboration:
 During this phase the project team is expected to capture a majority of system’s requirements (e.g., in the
form of use cases), to perform identified risk analysis and make a plan of risk management to reduce or
eliminate their impact on final schedule and product, to establish design and architecture (e.g., using
basic class diagrams, package diagrams and deployment diagrams), to create a plan (schedule, cost
estimates, and achievable milestones) for the next (construction) phase.

Constructions:
 the longest and largest phase within Unified Process.
 During this phase, the design of the system is finalized and refined and the system is built using the
basis created during elaboration phase.
 The construction phase is divided into multiple iterations, for each iteration to result in an executable
release of the system.

71
Transition:
 The final project phase which delivers the new system to its end-users.

 Transition phase includes also data migration from legacy systems and user trainings.

 The disciplines and phases of Unified Process are given in above diagram, where the phases are columns
and the disciplines are rows.

 It clearly shows that the relative effort across disciplines changes over time from iteration to iteration,
e.g., initial iterations apply greater relative effort on requirements and design while the latter—more on
testing and deployment.

72
 Usecase- defines the interaction between two or more entities

 Architectural centric-Blue print of organization of software system

 Iterative

 Incremental

73
Workflows

74
75
 Prescriptive Models or Conventional Models.

 Every software engineering organization should describe a unique set of framework activities for the software
processes it adopts.

 It should populate each framework activity with a set of software engineering actions, and define each action in terms
of a task set that identifies the work (and work products) to be accomplished to meet the development goals.

 It should then adapt the resultant process model to accommodate the specific nature of each project, the people who
will do the work and the environment in which the work will be conducted.

 Regardless of the process model that is selected, software engineers have traditionally chosen a generic process
framework that encompasses the following framework activities

76
 Communication :This framework activity involves heavy communication and collaboration with the
customer (and other stakeholders) and encompasses requirements gathering and related activities

 Planning :This activity establishes a plan for the software engineering work that follows. It describes
the technical tasks to be conducted, the risks that are likely, the resources that will be required, the
work products to be produced, and a work schedule

 Modeling:this activity encompasses the creation of models that allow the developer and the customer
to better understand software requirements and the design that will achieve those requirements.

 Construction :This activity combines code generation (either manual or automated) and the testing
that is required to uncover errors in the code.

77
 Deployment: The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the

delivered product and provides feedback based on the evaluation.

 We call these models prescriptive because they prescribe a set of process elements namely framework activities, software engineering

actions, tasks, work products, quality assurance and change control mechanisms for each project.

 Each process model also prescribes a workflow that is, the manner in which the process elements are interrelated to one another.

 All software process models can accommodate the generic framework activities, but each applies a different emphasis to these activities

and defines a workflow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner

78
 Object Oriented System Engineering
 In object-oriented software engineering, the software developer identifies and organizes the application in terms of
object-oriented concepts, prior to their final representation in any specific programming language or software tools

Phases in Object-Oriented Software Development

 The major phases of software development using object–oriented methodology are object-oriented analysis, object-
oriented design, and object-oriented implementation.

Object–Oriented Analysis
 In this stage, the problem is formulated, user requirements are identified, and then a model is built based upon real–
world objects. The analysis produces models on how the desired system should function and how it must be developed.

 The models do not include any implementation details so that it can be understood and examined by any non–technical
application expert.

79
Object–Oriented Design
 Object-oriented design includes two main stages, namely, system design and object design.

System Design
 In this stage, the complete architecture of the desired system is designed.

 Systems design is the process of defining the architecture, modules, interfaces, and data for a
system to satisfy specified requirements.

 Systems design could be seen as the application of systems theory to product development.

80
Object Design
 Object design is the process of planning a system of interacting objects for the purpose of

solving a software problem. It is one approach to software design

 Eg:Banking system

 All the classes required are identified. The designer decides whether
◦ new classes are to be created from scratch,
◦ any existing classes can be used in their original form, or
◦ new classes should be inherited from the existing classes

 Besides, the developer designs the internal details of the classes and their associations, i.e., the
data structure for each attribute and the algorithms for the operations.

81
Object–Oriented Implementation and Testing
 In this stage, the design model developed in the object design is translated into code in an

appropriate programming language or software tool.

 The databases are created and the specific hardware requirements are ascertained.

 Once the code is in shape, it is tested using specialized techniques to identify and remove the
errors in the code

Principles of Object-Oriented Systems

 The conceptual framework of object–oriented systems is based upon the object model.

 There are two categories of elements in an object-oriented system

82
Major Elements − By major, it is meant that if a model does not have any one of these elements, it
ceases(comes to end) to be object oriented. The four major elements are

 Abstraction-displaying only essential information and hiding the details

 Encapsulation- wrapping code and data together into a single unit. Eg:Capsule which is mixed of several
medicines)
 Modularity-Modules can be removed, replaced, or upgraded without affecting other components
(eg)Laptop and desktop
 Hierarchy- is a group of people or things arranged in order of rank or the people that rank at the top of
such a system.

Minor Elements − By minor, it is meant that these elements are useful, but not indispensable part of the
object model. The three minor elements are
 Typing

 Concurrency- means multiple computations are happening at the same time

 Persistence-Data that survive over several runs of your program

83
 Computer Based Systems

 The elements of computer-based systems are defined as software, hardware, people, database,
documentation, and procedures.

 A computer-based system makes use of a variety of system elements.

 Software: programs, data structures, and related work products.

 Hardware: electronic devices that provide computing capabilities.
 People: Users and operators of hardware and software.
 Database: A large, organized collection of information that is accessed via S/w and persists over time.
 Documentation: manuals, on-line help files.
 Procedures: the steps that define the specific use of each system element.

 One complicating characteristic of computer-based system is that the elements be a part of one
system may also represent one macro element of a still large system.

 The micro-element is a computer-based system that is one part of a larger computer based system.

84
 Verification
 The verifying process includes checking documents, design, code, and program.

Example of verification

 In Software Engineering, consider the following specification

 A clickable button with name Submet

 Verification would check the design doc and correcting the spelling mistake
.
 Otherwise, the development team will create a button like
◦ So new specification is

 A clickable button with name Submit

85
 Validation

 Validation is a dynamic mechanism of Software testing and validates the actual

product.

 Once the code is ready, Validation is done. A Validation test found –

 Owing to Validation testing, the development team will make the submit button
clickable.

86
Verification vs Validation

87
Continue..

88
 V-Model

 V-Model is also known as Verification and Validation Model.

 In this model Verification & Validation goes hand in hand i.e. development and
testing goes parallel.

 V model and waterfall model are the same except that the test planning and testing
start at an early stage in V-Model.

89
 Verification Phase:
(i) Requirement Analysis:
 In this phase, all the required information is gathered & analyzed. Verification

activities include reviewing the requirements.

(ii) System Design:
 Once the requirement is clear, a system is designed i.e. architecture, components

of the product are created and documented in a design document.

(iii) High-Level Design:
 High-level design defines the architecture/design of modules. It defines the

functionality between the two modules.

(iv) Low-Level Design:
 Low-level Design defines the architecture/design of individual components.

(v) Coding:
 Code development is done in this phase.

90
 Validation Phase
(i) Unit Testing:
 Unit Testing is performed using the unit test cases that are designed and is done in the Low-level
design phase. Unit testing is performed by the developer itself. It is performed on individual
components which lead to early defect detection.

(ii) Integration Testing:

 Integration testing is performed using integration test cases in High-level Design phase. Integration
testing is the testing that is done on integrated modules. It is performed by testers.

(iii) System Testing:

 System testing is performed in the System Design phase. In this phase, the complete system is tested
i.e. the entire system functionality is tested.

(iv) Acceptance Testing:

 Acceptance testing is associated with the Requirement Analysis phase and is done in the customer’s
environment.

91
 Advantages and Disadvantages

Advantages of V – Model:
 It is a simple and easily understandable model.

 V –model approach is good for smaller projects wherein the requirement is defined
and it freezes in the early stage.

 It is a systematic and disciplined model which results in a high-quality product.

Disadvantages of V-Model:
 V-shaped model is not good for ongoing projects.

 Requirement change at the later stage would cost too high.

92
 Life Cycle Process

 SDLC – is a continuous process, which starts from the moment, when it’s made a decision to launch the project, and
it ends at the moment of its full remove from the exploitation.

Basic Stages of Software Development Life Cycle:

Stage 1. Planning and requirement analysis

 Each software development life cycle model starts with the analysis, in which the stakeholders of the process
discuss the requirements for the final product.

 The goal of this stage is the detailed definition of the system requirements. Besides, it is needed to make sure that all
the process participants have clearly understood the tasks and how every requirement is going to be implemented.

 Often, the discussion involves the QA specialists who can interfere the process with additions even during the
development stage if it is necessary.

93
Stage 2. Designing project architecture

 At the second phase of the software development life cycle, the developers are actually designing
the architecture.

 All the different technical questions that may appear on this stage are discussed by all the
stakeholders, including the customer.

 Also, here are defined the technologies used in the project, team load, limitations, time frames,
and budget.

 The most appropriate project decisions are made according to the defined requirements.

94
Stage 3. Development and programming

 After the requirements approved, the process goes to the next stage – actual development.

 Programmers start here with the source code writing while keeping in mind previously defined
requirements.

 The system administrators adjust the software environment, front-end programmers develop the
user interface of the program and the logics for its interaction with the server.

 The programming by itself assumes four stages

◦ Algorithm development
◦ Source code writing
◦ Compilation
◦ Testing and debugging

95
Stage 4. Testing

 The testing phase includes the debugging process.

 All the code flaws missed during the development are detected here, documented, and passed
back to the developers to fix.

 The testing process repeats until all the critical issues are removed and software workflow is
stable.

96
Stage 5. Deployment
 When the program is finalized and has no critical issues – it is time to launch it for the end
users.

 After the new program version release, the tech support team joins.

 This department provides user feedback; consult and support users during the time of
exploitation.

 Moreover, the update of selected components is included in this phase, to make sure, that the
software is up-to-date and is invulnerable to a security breach.

97
 System Engineering

 Software engineering occurs as a consequence of a process called system engineering.

 The overall objective of the system must be determined:

 The role of hardware, software, people, database, procedures, and other system elements must be identified
 Operational requirements must be elicited/extracted, analyzed, specified, modeled, validated, and managed.
 These activities are the foundation of system engineering.

 System engineering is a modeling process.

 To construct a system model, the engineer should consider a number of factors:
◦ Assumptions
◦ Simplifications
◦ Limitations
◦ Constraints
◦ Preferences

98
 Assumptions:Reduce the number of possible permutations and variations.

 Simplifications: enable the model to be created in a timely manner.

 Limitations: Help to bound the system.

 Constraints: Will guide the manner in which the model is created and the approach taken when the model
is implemented.

 Preferences: Indicate the preferred architecture for all data, functions, and technology.

99
 System Engineering Hierarchy
 System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy

 For software development this means creating a "world view" and progressively narrowing its focus until all
technical detail is known.

 Within a specific domain, the need for targeted system elements is analyzed.

 Finally, the analysis, design, and construction of targeted system element is initiated.

 Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are
conducted.

 It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

10
0
10
1
 The world view (WV) is composed of a set of domains (D1), which can each be a system or
system of systems in its own right

WV = {D1 D2 D3………,Dn }

 Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain and component:

Di = {E1 E2 E3 …… Em}

 Finally, each element is implemented by specifying the technical components (Ck) that achieve
the necessary function for an element:

Ej = {C1, C2 C3 …….. C k}

 In the software context, a component could be a computer program, a reusable program

component, a module, a class or object, or even a programming language statement.

10
2
10
3
Business Process Engineering: An Overview

 The goal of Business Process Engineering (BPE) is to define architectures that will enable a business to use
information effectively.

 BPE is one process for creating an overall plan for implementing the computing architecture

 Three architectures must be analyzed and designed within the context of business objectives and goals:

 Data Architecture
◦ It provides a framework for the information needs of a business or business function

 Applications architecture
◦ It encompasses those elements of a system that transform objects within the data architecture for business
purpose

 Technology Infrastructure
◦ It provides foundation for data and application architectures. Infrastructure encompasses hardware and
software that are used to support the application and data

10
4
Product Engineering: An Overview

 Emphasize that software engineers participate in all levels of the product engineering process
that begins with requirements engineering.

 The analysis step maps requirements into representations of data, function, and behavior.

 The design step maps the analysis model into data, architectural, interface, and software
component designs.

10
5
10
6
 The Goal of product Engineering is to translate the customer's device for a set of defined
capabilities into a working product

 Architecture consists of 4 components

◦ Software
◦ Hardware
◦ data
◦ People

Business Process Reengineering

 It is Iterative like other business process

 Business goals and the process that achieve them must be adopted to a changing business
environment

10
7
10
8
The model defines 6 activities
 Business Definition

Business goals are identified within context of four key drivers-Cost reduction, time
reduction,quality environment and personal development,empowerment

 Process Identification

Process defined in the business process are identified,then ranked by importance for re
engineering activity

 Process Evaluation
Existing process is analyzed and measured,cost and time consumed from the tasks are
noted and quality/performance process are isolated

10
9
 Process specification and design:

Use cases prepared each process is re designed based on first three activities

 Prototyping

A redesigned must be prototyped before it is fully integrated into the business

 Refinement
Based on the feedback from the prototype, business process are refined

11
0
 System Modeling
System modeling is an important element of the system engineering process. Whether the focus is on the world
view or the detailed view, the engineer creates models that:

• Define the process that serves the needs of the view under consideration.
• Represent the behavior of the processes and the assumption on which the behavior is based.

To construct a system model, the engineer should consider a number of restraining factors:

1. Assumption that reduce the number of possible permutations and variations, thus enabling a model to reflect the
problem in a reasonable manner.
2. Simplifications that the model has to create in a timely manner.
3. Limitations that help to bound the system.
4. Constraints that will guide the manner in which the model is created and the approach taken when the model is
implemented.
5. Preference that indicate the preferred architecture for all data, functions, and technology.

11
1
 Capability Maturity Model

 The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software
development process.

 Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software
process.

 CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and
development center promote by the U.S. Department of Defense (DOD)

Methods of SEICMM
 There are two methods of SEICMM:

11
2
Capability Evaluation:
 Capability evaluation provides a way to assess the software process capability of an organization.

 The results of capability evaluation indicate the likely contractor performance if the contractor is awarded
a work.

 Therefore, the results of the software process capability assessment can be used to select a contractor.

Software Process Assessment:

 Software process assessment is used by an organization to improve its process capability.

 Thus, this type of evaluation is for purely internal use.

11
3
CMM Levels

11
4
Level 1: Initial
 Ad hoc activities characterize a software development organization at this level.

 Very few or no processes are described and followed.

 Since software production processes are not limited, different engineers follow their process and as a
result, development efforts become chaotic.

 Therefore, it is also called a chaotic level.

Level 2: Repeatable
 At this level, the fundamental project management practices like tracking cost and schedule are

established.

 Size and cost estimation methods, like function point analysis, COCOMO, etc. are used.

11
5
Level 3: Defined
 At this level, the methods for both management and development activities are defined and documented. There is a
common organization-wide understanding of operations, roles, and responsibilities.

 The ways through defined, the process and product qualities are not measured. ISO 9000 goals at achieving this
level.

Level 4: Managed
 At this level, the focus is on software metrics. Two kinds of metrics are composed.

 Product metrics measure the features of the product being developed, such as its size, reliability, time complexity,
understandability, etc.

 Process metrics follow the effectiveness of the process being used, such as average defect correction time,
productivity, the average number of defects found per hour inspection, the average number of failures detected
during testing per LOC, etc.

 The software process and product quality are measured, and quantitative quality requirements for the product are
met.

11
6
 Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the product and process
quality.

 The process metrics are used to analyze if a project performed satisfactorily.

 Thus, the outcome of process measurements is used to calculate project performance rather than improve
the process.

Level 5: Optimizing
 At this phase, process and product metrics are collected. Process and product measurement data are

evaluated for continuous process improvement.

11
7
 Key Process Areas (KPA) of a software organization

 Except for SEI CMM level 1, each maturity level is featured by several Key Process Areas (KPAs) that contains the areas an
organization should focus on improving its software process to the next level. The focus of each level and the corresponding
key process areas are shown in the following table

11
8
Use of CMM:
 Today CMM act as a "seal of approval" in the software industry. It helps in various
ways to improve the software quality.
 It guides towards repeatable standard process and hence reduce the learning time
on how to get things done
 Practicing CMM means practicing standard protocol for development, which
means it not only helps the team to save time but also gives a clear view of what to
do and what to expect
 The quality activities gel well with the project rather than thought of as a separate
event
 It acts as a commuter between the project and the team
 CMM efforts are always towards the improvement of the process

12
2
 Limitations

 CMM determines what a process should address instead of how it should be

implemented

 It does not explain every possibility of software process improvement

 It concentrates on software issues but does not consider strategic business planning,
adopting technologies, establishing product line and managing human resources

 It does not tell on what kind of business an organization should be in

 CMM will not be useful in the project having a crisis right now

12
3