UNIT - I SOFTWARE PROCESS MODEL 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. Definition of software: - it is systematic approach to the development, operation, maintenance and retirement of software. It is the application of computer science along with mathematics and ergative science. In the current scenario the S.E has a specific importance for making particular software. Set of instruction-> this is program. Set of program-> software. DIFFERENCE OF PROGRAM AND SOFTWARE This software is a collection of computer programs, procedure, rules and associative documentation and data. Program is generally used the developer of a specific program to make a particular software. program software 1) Small in size. 2) Authors himself is user-soul. 3) Single developer. 4) Adopt development. 5) Lack proper interface. 6) Large proper documentation. 1) Large in size. 2) Large number. 3) Team developer. 4) Systematic development. 5) Well define interface. 6) Well documented. Some characteristics of software includes:- 1) Software is developed or engineer. 2) Most of software is custom build rather than assemble from existing component. 3) Computer program and associated documentation. 4) Easy to modified. 5) Easy to reproduce. 6) Software product may be developed for a particular customer or for the general market. Why software engineering:- 1) In the late 1960’s hardware price were falling but software price rising. 2) Many software projects failed. 3) Large software project required large development loams.
116
Embed
UNIT - I SOFTWARE PROCESS MODEL Software software product. · UNIT - I SOFTWARE PROCESS MODEL Software is more than just a program code. A program is an executable code, which serves
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIT - I SOFTWARE PROCESS MODEL
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.
Definition of software: - it is systematic approach to the development, operation, maintenance
and retirement of software. It is the application of computer science along with mathematics and
ergative science. In the current scenario the S.E has a specific importance for making particular
software.
Set of instruction-> this is program.
Set of program-> software.
DIFFERENCE OF PROGRAM AND SOFTWARE
This software is a collection of computer programs, procedure, rules and associative
documentation and data. Program is generally used the developer of a specific program to make
a particular software.
program software
1) Small in size.
2) Authors himself is user-soul.
3) Single developer.
4) Adopt development.
5) Lack proper interface.
6) Large proper documentation.
1) Large in size.
2) Large number.
3) Team developer.
4) Systematic development.
5) Well define interface.
6) Well documented.
Some characteristics of software includes:-
1) Software is developed or engineer.
2) Most of software is custom build rather than assemble from existing component.
3) Computer program and associated documentation.
4) Easy to modified.
5) Easy to reproduce.
6) Software product may be developed for a particular customer or for the general market.
Why software engineering:-
1) In the late 1960’s hardware price were falling but software price rising.
2) Many software projects failed.
3) Large software project required large development loams.
4) Many software project late and over budget.
5) Complicity of software project is increased.
6) Demand for new software on the market.
Why study software engineering?
1) Higher productivity.
2) To acquire skills to develop large programs.
3) Ability to solve complex programming problems.
4) Learn techniques of specification design.
5) Better quality programmers.
Applications of software:-
1) System software
2) Application software.
3) Engineering/scientific software.
4) Embedded software.
5) Product line software.
6) Web application software.
7) Artificial intelligence software (AI).
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.
Definitions
IEEE defines software engineering as:
(1) The application of a systematic,disciplined,quantifiable approach to the
development,operation and maintenance of software; that is, the application of engineering to
software.
(2) The study of approaches as in the above statement.
Fritz Bauer, a German computer scientist, defines software engineering as:
Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and work efficiently on real machines.
Software Evolution
The process of developing a software product using software engineering principles and methods
is referred to as software evolution. This includes the initial development of software and its
maintenance and updates, till desired software product is developed, which satisfies the expected
requirements.
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. 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.
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.
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.
Software Paradigms
Software paradigms refer to the methods and steps, which are taken while designing the
software. There are many methods proposed and are in work today, but we need to see where in
the software engineering these paradigms stand. These can be combined into various categories,
though each of them is contained in one another:
Programming paradigm is a subset of Software design paradigm which is further a subset of
Software development paradigm.
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 includes various researches and
requirement gathering which helps the software product to build. 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
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.
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
Well-engineered and crafted software is expected to have the following characteristics:
Operational
This tells us how well software works in operations. It can be measured on:
Budget
Usability
Efficiency
Correctness
Functionality
Dependability
Security
Safety
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
In short, 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.
Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of
stages in software engineering to develop the intended software product.
SDLC Activities
SDLC provides a series of steps to be followed to design and develop a software product
efficiently. SDLC framework includes the following steps:
Communication
This is the first step where the user initiates the request for a desired software product. He
contacts the service provider and tries to negotiate the terms. He submits his request to the
service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the project. The team holds
discussions with various stakeholders from problem domain and tries to bring out as much
information as possible on their requirements. The requirements are contemplated and segregated
into user requirements, system requirements and functional requirements. The requirements are
collected using a number of practices as given -
studying the existing or obsolete system and software,
conducting interviews of users and developers,
referring to the database or
collecting answers from the questionnaires.
Feasibility Study
After requirement gathering, the team comes up with a rough plan of software process. At this
step the team analyzes if a software can be made to fulfill all requirements of the user and if
there is any possibility of software being no more useful. It is found out, if the project is
financially, practically and technologically feasible for the organization to take up. There are
many algorithms available, which help the developers to conclude the feasibility of a software
project.
System Analysis
At this step the developers decide a roadmap of their plan and try to bring up the best software
model suitable for the project. System analysis includes Understanding of software product
limitations, learning system related problems or changes to be done in existing systems
beforehand, identifying and addressing the impact of project on organization and personnel etc.
The project team analyzes the scope of the project and plans the schedule and resources
accordingly.
Software Design
Next step is to bring down whole knowledge of requirements and analysis on the desk and design
the software product. The inputs from users and information gathered in requirement gathering
phase are the inputs of this step. The output of this step comes in the form of two designs; logical
design and physical design. Engineers produce meta-data and data dictionaries, logical diagrams,
data-flow diagrams and in some cases pseudo codes.
Coding
This step is also known as programming phase. The implementation of software design starts in
terms of writing program code in the suitable programming language and developing error-free
executable programs efficiently.
Testing
An estimate says that 50% of whole software development process should be tested. Errors may
ruin the software from critical level to its own removal. Software testing is done while coding by
the developers and thorough testing is conducted by testing experts at various levels of code such
as module testing, program testing, product testing, in-house testing and testing the product at
user’s end. Early discovery of errors and their remedy is the key to reliable software.
Integration
Software may need to be integrated with the libraries, databases and other program(s). This stage
of SDLC is involved in the integration of software with outer world entities.
Implementation
This means installing the software on user machines. At times, software needs post-installation
configurations at user end. Software is tested for portability and adaptability and integration
related issues are solved during implementation.
Operation and Maintenance
This phase confirms the software operation in terms of more efficiency and less errors. If
required, the users are trained on, or aided with the documentation on how to operate the
software and how to keep the software operational. The software is maintained timely by
updating the code according to the changes taking place in user end environment or technology.
This phase may face challenges from hidden bugs and real-world unidentified problems.
Disposition
As time elapses, the software may decline on the performance front. It may go completely
obsolete or may need intense upgradation. Hence a pressing need to eliminate a major portion of
the system arises. This phase includes archiving data and required software components, closing
down the system, planning disposition activity and terminating system at appropriate end-of-
system time.
Software Development Lifecycle (SDLC)
Software development lifecycle or SDLC is a structured, tried and tested methodology for
development of software products across the world. SDLC consists of a series of steps that any
software developer should follow in order to build a software product effectively and efficiently.
All the software development lifecycle approaches that we are going to discuss below can
accommodate the generic paradigm discussed in the previous section. We have five major
approaches or models proposed by different experts. Before we get into the models, let us
discuss briefly about the different steps involved in software development, which is common to
all models. The different steps involved are:
Planning –
Here the detailed requirement analysis is done, followed by a detailed roadmap for software
development. List of deliverables, various stakeholders involved and clear roles and
responsibilities are laid out along with appropriate documentation and reporting metrics. This
gives the client and overview of the whole plan.
Defining –
All the client requirements are broken down in detail. Top level requirements are broken down
into specific set of modules and sub-components. Every module and sub-component is defined
properly along with its functionalities and how it would be integrated.
Designing –
In this step, the detailed requirements are analysed and a software design is made. Software
design consists of two different types of designs – logical design and physical design. In logical
design, the overall architecture along with all modules and sub-modules, data transfer between
then and how it integrates with the existing system – is clearly drafted through various diagrams.
Physical design is all about the hardware requirements for software deployment.
Development –
This is the actual step where the software development or coding happens. The modules as
drafted in the design phase are given to multiple teams for coding.
Testing –
All the modules, sub-components that are developed are tested for their respective functionalities
here. This step utilises multiple tools and techniques to identify and fix defects.
Deployment –
The software developed is implemented in client premises. The development team works along
with client teams to ensure that the deployment is smooth and seamless.
INTRODUCTION - SOFTWARE PROCESS MODEL
DEFINITION:
A software process model is an abstract representation of a process. It presents a description of
a process. When we describe and discuss processes, we usually talk about the activities in
these processes such as specifying a data model, designing a user interface, etc. and the ordering
of these activities.
In software development life cycle, various models are designed and defined. These models are
called as Software Development Process Models.
On the basis of project motive, the software development process model is selected for
development.
Following are the different software development process models:
1) Big-Bang model
2) Code-and-fix model
3) Waterfall model
4) V model
5) Incremental model
6) RAD model
7) Agile model
8) Iterative model
9) Spiral model
10) Prototype model
The following framework activities are carried out irrespective of the process model chosen by
the organization.
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
PRESCRIPTIVE PROCESS MODELS
The name 'prescriptive' is given because the model prescribes a set of activities, actions, tasks,
quality assurance and change the mechanism for every project.
There are three types of prescriptive process models. They are:
1. The Waterfall Model
2. Incremental Process model
3. RAD model
1. The Waterfall Model
The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle
model'.
In this model, each phase is fully completed before the beginning of the next phase.
This model is used for the small projects.
In this model, feedback is taken after each phase to ensure that the project is on the right
path.
Testing part starts only after the development is complete.
NOTE: The description of the phases of the waterfall model is same as that of the process
model.
An alternative design for 'linear sequential model' is as follows:
The Waterfall Model also referred to as the sequential lifecycle model was the first model
to be accepted widely in the software industry. This model applies best to projects where there is
minimum uncertainty.
In the waterfall model, every phase of development is completed fully before the next
phase begins. For this reason, each phase is well-defined with a definitive set of objectives.
THE VARIOUS PHASES ARE
Requirements – In this phase, all the requirements are clearly identified and necessary
clarifications are done with the client. The detailed requirements thus obtained are
documented clearly in the specification document.
Design – Based on the requirements gathered, a system design is developed in the design
phase. Specific hardware and system requirements are clearly identified and the overall
system architecture is designed in this phase.
Implementation – Once the system design and architecture are developed, the software
program is developed. If it’s a complex software, then it is broken down into different
modules and then these modules are developed.
Verification – The software program developed is verified and tested thoroughly to see that
all the required functionalities are included. The verification is first for individual modules
and then once the modules are integrated, the overall functionality is verified and tested.
Maintenance – Even after all the rigorous development and testing is done, there could be
some issues that may not be captured during the initial phases. As and when such issues are
captured, they are taken up for development and deployment during the maintenance phase.
In this phase, such issues are resolved through patches of code. Sometimes, the software by
itself is upgraded with better features during maintenance phase. Mostly maintenance is done
after the system gets integrated in the customer environment.
Advantages of waterfall model
The waterfall model is simple and easy to understand, implement, and use.
All the requirements are known at the beginning of the project, hence it is easy to
manage.
It avoids overlapping of phases because each phase is completed at once.
This model works for small projects because the requirements are understood very well.
This model is preferred for those projects where the quality is more important as
compared to the cost of the project.
Disadvantages of the waterfall model
This model is not good for complex and object oriented projects.
It is a poor model for long projects.
The problems with this model are uncovered, until the software testing.
The amount of risk is high.
V – model
The major drawback of waterfall model is we move to the next stage only when the previous one
is finished and there was no chance to go back if something is found wrong in later stages. V-
Model provides means of testing of software at each stage in reverse manner.
At every stage, test plans and test cases are created to verify and validate the product according
to the requirement of that stage. For example, in requirement gathering stage the test team
prepares all the test cases in correspondence to the requirements. Later, when the product is
developed and is ready for testing, test cases of this stage verify the software against its validity
towards requirements at this stage.
This makes both verification and validation go in parallel. This model is also known as
verification and validation model.
2. Incremental Process model
The incremental model combines the elements of waterfall model and they are applied in an
iterative fashion.
The first increment in this model is generally a core product.
Each increment builds the product and submits it to the customer for any suggested
modifications.
The next increment implements on the customer's suggestions and add additional requirements in
the previous increment.
This process is repeated until the product is finished.
For example, the word-processing software is developed using the incremental model.
Advantages of incremental model
This model is flexible because the cost of development is low and initial product delivery is
faster.
It is easier to test and debug during the smaller iteration.
The working software generates quickly and early during the software life cycle.
The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
The cost of the final product may cross the cost estimated initially.
This model requires a very clear and complete planning.
The planning of design is required before the whole system is broken into small increments.
The demands of customer for the additional functionalities after every increment causes
problem during the system architecture.
RAD (Rapid Application Development) model
RAD is a Rapid Application Development model.
Using the RAD model, software product is developed in a short period of time.
The initial activity starts with the communication between customer and developer.
Planning depends upon the initial requirements and then the requirements are divided into
groups.
Planning is more important to work together on different modules.
The RAD model consist of following phases:
1) Business Modeling
2) Data modeling
3) Process modeling
4) Application generation
5) Testing and turnover
1) Business Modeling
Business modeling consists of the flow of information between various functions in the
project.
For example, what type of information is produced by every function and which are the
functions to handle that information.
It is necessary to perform complete business analysis to get the essential business
information.
2) Data modeling
The information in the business modeling phase is refined into the set of objects and it is
essential for the business.
The attributes of each object are identified and defined the relationship between objects.
3) Process modeling
The data objects defined in the data modeling phase are changed to fulfil the information
flow to implement the business model.
The process description is created for adding, modifying, deleting or retrieving a data object.
4) Application generation
In the application generation phase, the actual system is built.
To construct the software the automated tools are used.
5) Testing and turnover
The prototypes are independently tested after each iteration so that the overall testing time is
reduced.
The data flow and the interfaces between all the components are fully tested. Hence, most of
the programming components are already tested.
Advantages of RAD Model
The process of application development and delivery are fast.
This model is flexible, if any changes are required.
Reviews are taken from the clients at the staring of the development hence there are lesser
chances to miss the requirements.
Disadvantages of RAD Model
The feedback from the user is required at every development phase.
This model is not a good choice for long term and large projects.
Evolutionary Models
• Software system evolves over time as requirements often change as development proceeds.
Thus, a straight line to a complete end product is not possible. However, a limited version must
be delivered to meet competitive pressure.
• Usually a set of core product or system requirements is well understood, but the details and
extension have yet to be defined.
• You need a process model that has been explicitly designed to accommodate a product that
evolved over time.
• It is iterative that enables you to develop increasingly more complete version of the software.
• Two types are introduced, namely Prototyping and Spiral models.
Evolutionary Models: PROTOTYPING
• When to use: Customer defines a set of general objectives but does not identify detailed
requirements for functions and features. Or Developer may be unsure of the efficiency of an
algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the objective,
identify whatever requirements are known, outline areas where further definition is mandatory. A
quick plan for prototyping and modeling (quick design) occur. Quick design focuses on a
representation of those aspects the software that will be visible to end users. ( interface and
output). Design leads to the construction of a prototype which will be deployed and evaluated.
Stakeholder’s comments will be used to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for
the actual system, and developers get to build something immediately. However, engineers may
make compromises in order to get a prototype working quickly. The lessthan- ideal choice may
be adopted forever after you get used to it.
The Prototyping model
Prototype is defined as first or preliminary form using which other forms are copied or
derived.
Prototype model is a set of general objectives for software.
It does not identify the requirements like detailed input, output.
It is software working model of limited functionality.
In this model, working programs are quickly produced.
Evolutionary Models: Prototyping
The different phases of Prototyping model are:
1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.
2. Quick design
Quick design is implemented when requirements are known.
It includes only the important aspects like input and output format of the software.
It focuses on those aspects which are visible to the user rather than the detailed plan.
It helps to construct a prototype.
3. Modeling quick design
This phase gives the clear idea about the development of software because the software
is now built.
It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.
5. Deployment, delivery, feedback
If the user is not satisfied with current prototype then it refines according to the
requirements of the user.
The process of refining the prototype is repeated until all the requirements of users are
met.
When the users are satisfied with the developed prototype then the system is developed
on the basis of final prototype.
Advantages of Prototyping Model
Prototype model need not know the detailed input, output, processes, adaptability of
operating system and full machine interaction.
In the development process of this model users are actively involved.
The development process is the best platform to understand the system by the user.
Errors are detected much earlier.
Gives quick user feedback for better solutions.
It identifies the missing functionality easily. It also identifies the confusing or difficult
functions.
Disadvantages of Prototyping Model:
The client involvement is more and it is not always considered by the developer.
It is a slow process because it takes more time for development.
Many changes can disturb the rhythm of the development team.
It is a thrown away prototype when the users are confused with it.
Spiral Model
Spiral model is a combination of both, iterative model and one of the SDLC model. It can be
seen as if you choose one SDLC model and combine it with cyclic process (iterative model).
This model considers risk, which often goes un-noticed by most other models. The model
starts with determining objectives and constraints of the software at the start of one iteration.
Next phase is of prototyping the software. This includes risk analysis. Then one standard SDLC
model is used to build the software. In the fourth phase of the plan of next iteration is prepared.
Spiral model is a risk driven process model.
It is used for generating the software projects.
In spiral model, an alternate solution is provided if the risk is found in the risk analysis,
then alternate solutions are suggested and implemented.
It is a combination of prototype and sequential model or waterfall model.
In one iteration all activities are done, for large project's the output is small.
Evolutionary Models: The Spiral
STEPS OF SPIRAL MODEL
• It couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model and is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk. The other is a set of
anchor point milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be
a model or prototype. During later iterations, increasingly more complete version of the
engineered system are produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent
passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software. Each pass results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback. Also, the number of iterations will be adjusted by
project manager.
• Good to develop large-scale system as software evolves as the process progresses and risk
should be understood and properly reacted to. Prototyping is used to reduce risk.
• However, it may be difficult to convince customers that it is controllable as it demands
considerable risk assessment expertise.
Advantages of Spiral Model
It reduces high amount of risk.
It is good for large and critical projects.
It gives strong approval and documentation control.
In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model
It can be costly to develop a software model.
It is not used for small projects.
Three Concerns on Evolutionary Processes
• First concern is that prototyping poses a problem to project planning because of the uncertain
number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the evolution occur too
fast, without a period of relaxation, it is certain that the process will fall into chaos. On the other
hand if the speed is too slow then productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility rather than on high
quality. We should prioritize the speed of the development over zero defects. Extending the
development in order to reach high quality could result in a late delivery of the product when the
opportunity niche has disappeared.
3. The concurrent development model
The concurrent development model is called as concurrent model.
The communication activity has completed in the first iteration and exits in the awaiting
changes state.
The modeling activity completed its initial communication and then go to the
underdevelopment state.
If the customer specifies the change in the requirement, then the modeling activity moves
from the under development state into the awaiting change state.
The concurrent process model activities moving from one state to another state.
STEPS OF CONCURRENT MODEL
• Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
• The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into
the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling is applicable to all types of software development and provides an
accurate picture of the current state of a project. Rather than confining software
engineering activities, actions and tasks to a sequence of events, it defines a process
network. Each activity, action or task on the network exists simultaneously with other
activities, actions or tasks. Events generated at one point trigger transitions among the
states.
Advantages of the concurrent development model
This model is applicable to all types of software development processes.
It is easy for understanding and use.
It gives immediate feedback from testing.
It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
It needs better communication between the team members. This may not be achieved all
the time.
It requires to remember the status of the different activities.
SPECIALISED PROCESS MODELS
Special process models take many features from one or more conventional models. However
these special models tend to be applied when a narrowly defined software engineering approach
is chosen.
Types in Specialized process models:
1. Component based development (Promotes reusable components)
2. The formal methods model (Mathematical formal methods are backbone here)
3. Aspect oriented software development (Uses crosscutting technology)
Component based development
The component based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of
software. However, the model focuses on prepackaged software components. It promotes
software reusability.
Component based development Modeling and construction activities begin with the
identification of candidate components. Candidate components can be designed as either
conventional software modules or object oriented packages.
Component based development has the following steps:
1. Available component based products are researched and evaluated for the application domain.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
Problems in Component based development
Component trustworthiness - how can a component with no available source code be trusted?
Component certification - who will certify the quality of components?
Requirements trade-offs - how do we do trade-off analysis between the features of one
component and another?
The formal methods model
The formal methods model encompasses a set of activities that leads to formal mathematical
specification of software. Formal methods enable a software engineer to specify, develop and
verify a computer system by applying rigorous mathematical notation.
When mathematical methods are used during software development, they provide a mechanism
for eliminating many of the problems that are difficult to overcome using other software
engineering paradigms.
Formal methods provide a basis for software verification and therefore enable software engineer
to discover and correct errors that might otherwise go undetected.
Problems in formal methods model
The development of formal models is currently time-consuming and expensive.
Because few developers have the necessary background knowledge to apply formal methods,
extensive training is required to others.
It is difficult to use this model as a communication mechanism for technically unsophisticated
people.
Aspect oriented Software Development
Aspect Oriented Software Development (AOSD) often referred to as aspect oriented
programming (AOP), a relatively new paradigm that provides process and methodology for
defining, specifying designing and constructing aspects.
It addresses limitations inherent in other approaches, including object-oriented programming.
AOSD aims to address crosscutting concerns by providing means for systematic identification,
separation, representation and composition.
This results in better support for modularization hence reducing development, maintenance and
evolution costs.
Rational Unified Process (RUP)
Rational Unified Process (RUP) is an object-oriented and Web-enabled program
development methodology. According to Rational (developers of Rational Rose and the Unified
Modeling Language), RUP is like an online mentor that provides guidelines, templates, and
examples for all aspects and stages of program development. RUP and similar products -- such
as Object-Oriented Software Process (OOSP), and the OPEN Process -- are comprehensive
software engineering tools that combine the procedural aspects of development (such as defined
stages, techniques, and practices) with other components of development (such as documents,
models, manuals, code, and so on) within a unifying framework.
RUP Stands for "Rational Unified Process." RUP is a software development process from
Rational, a division of IBM. It divides the development process into four distinct phases that
each involve business modeling, analysis and design, implementation, testing, and deployment.
The four phases are:
1. Inception - The idea for the project is stated. The development team determines if the
project is worth pursuing and what resources will be needed.
2. Elaboration - The project's architecture and required resources are further evaluated.
Developers consider possible applications of the software and costs associated with the
development.
3. Construction - The project is developed and completed. The software is designed,
written, and tested.
4. Transition - The software is released to the public. Final adjustments or updates are
made based on feedback from end users.
The RUP development methodology provides a structured way for companies to envision create
software programs. Since it provides a specific plan for each step of the development process, it
helps prevent resources from being wasted and reduces unexpected development costs.
The Unified Process (UP) is an attempt to draw on the best features and characteristics of
conventional software process models, but characterize them in a way that implements
many of the best principles of agile software development.
The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system.
It helps the architect to focus on the right goals, such as understandability, reliance to
The main advantage of object oriented design is that improving the software
development and maintainability.
Another advantage is that faster and low cost development, and creates a high quality
software.
The disadvantage of the object-oriented design is that larger program size and it is not
suitable for all types of program.
Design classes
A set of design classes refined the analysis class by providing design details.
There are five different types of design classes and each type represents the layer of the
design architecture these are as follows:
1. User interface classes
These classes are designed for Human Computer Interaction(HCI).
These interface classes define all abstraction which is required for Human Computer
Interaction(HCI).
2. Business domain classes
These classes are commonly refinements of the analysis classes.
These classes are recognized as attributes and methods which are required to implement
the elements of the business domain.
3. Process classes
It implement the lower level business abstraction which is needed to completely manage the
business domain class.
4. Persistence classes
It shows data stores that will persist behind the execution of the software.
5. System Classes System classes implement software management and control functions that allow to operate and
communicate in computing environment and outside world.
Design class characteristic
The characteristic of well formed designed class are as follows:
1. Complete and sufficient
A design class must be the total encapsulation of all attributes and methods which are required to
exist for the class.
2. Primitiveness
The method in the design class should fulfil one service for the class.
If service is implemented with a method then the class should not provide another way to
fulfil same thing.
3. High cohesion
A cohesion design class has a small and focused set of responsibilities.
For implementing the set of responsibilities the design classes are applied single-
mindedly to the methods and attribute.
4. Low-coupling
All the design classes should collaborate with each other in a design model.
The minimum acceptable of collaboration must be kept in this model.
If a design model is highly coupled then the system is difficult to implement, to test and
to maintain over time.
Following are the types of design elements:
1. Data design elements
The data design element produced a model of data that represent a high level of
abstraction.
This model is then more refined into more implementation specific representation which
is processed by the computer based system.
The structure of data is the most important part of the software design.
2. Architectural design elements
The architecture design elements provides us overall view of the system.
The architectural design element is generally represented as a set of interconnected
subsystem that are derived from analysis packages in the requirement model.
The architecture model is derived from following sources:
The information about the application domain to built the software.
Requirement model elements like data flow diagram or analysis classes, relationship and
collaboration between them.
The architectural style and pattern as per availability.
3. Interface design elements
The interface design elements for software represents the information flow within it and
out of the system.
They communicate between the components defined as part of architecture.
Following are the important elements of the interface design: 1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.
4. Component level diagram elements
The component level design for software is similar to the set of detailed specification of
each room in a house.
The component level design for the software completely describes the internal details of
the each software component.
The processing of data structure occurs in a component and an interface which allows all
the component operations.
In a context of object-oriented software engineering, a component shown in a UML
diagram.
The UML diagram is used to represent the processing logic.
5. Deployment level design elements
The deployment level design element shows the software functionality and subsystem
that allocated in the physical computing environment which support the software.
Following figure shows three computing environment as shown. These are the personal
computer, the CPI server and the Control panel.
Software Architecture Introduction
The concept of software architecture is similar to the architecture of building.
The architecture is not an operational software.
The software architecture focuses on the role of software components.
Software components consist of a simple program module or an object oriented class in
an architectural design.
The architecture design extended and it consists of the database and the middleware that
allows the configuration of a network of clients and servers.
Importance of software architecture
Following are the reasons for the importance of software architecture.
1. The representation of software architecture allows the communication between all stakeholder
and the developer.
2. The architecture focuses on the early design decisions that impact on all software engineering
work and it is the ultimate success of the system.
3. The software architecture composes a small and intellectually graspable model.
4. This model helps the system for integrating the components using which the components are
work together.
The architectural style
The architectural style is a transformation and it is applied to the design of an entire
system.
The main aim of architectural style is to build a structure for all components of the
system.
An architecture of the system is redefined by using the architectural style.
An architectural pattern such as architectural style introduces a transformation on the
design of an architecture.
The software is constructed for computer based system and it shows one of the
architectural style from many of style.
The design categories of architectural styles includes:
1. A set of components such as database, computational modules which perform the function
required by the system.
2. A set of connectors that allows the communication, coordination and cooperation between the
components.
3. The constraints which define the integration of components to form the system.
4. Semantic model allows a designer to understand the overall properties of a system by using
analysis of elements.
Architectural design
The architectural design starts then the developed software is put into the context.
The information is obtained from the requirement model and other information collect
during the requirement engineering.
Representing the system in context
All the following entities communicates with the target system through the interface that is small
rectangles shown in above figure.
Superordinate system
These system use the target system like a part of some higher-level processing scheme.
Subordinate system This systems is used by the target system and provide the data mandatory to complete target
system functionality.
Peer-level system These system interact on peer-to-peer basis means the information is consumed by the target
system and the peers.
Actors These are the entities like people, device which interact with the target system by consuming
information that is mandatory for requisite processing.
Defining Archetype
An archetype is a class or pattern which represents a core abstraction i.e critical to
implement or design for the target system.
A small set of archetype is needed to design even the systems are relatively complex.
The target system consists of archetype that represent the stable elements of the
architecture.
Archetype is instantiated in many different forms based on the behavior of the system.
In many cases, the archetype is obtained by examining the analysis of classes defined as a
part of the requirement model.
An Architecture Trade-off Analysis Method (ATAM)
ATAM was developed by the Software Engineering Institute (SEI) which started an iterative
evaluation process for software architecture.
The design analysis activities which are executed iteratively that are as follows:
1. Collect framework
Collect framework developed a set of use cases that represent the system according to user point
of view.
2. Obtained requirement, Constraints, description of the environment.
These types of information are found as a part of requirement engineering and is used to verify
all the stakeholders are addressed properly.
3. Describe the architectural pattern
The architectural patterns are described using an architectural views which are as follows:
Module view: This view is for the analysis of assignment work with the components and the
degree in which abstraction or information hiding is achieved
Process view: This view is for the analysis of the software or system performance.
Data flow view: This view analyzes the level and check whether functional requirements are met
to the architecture.
4. Consider the quality attribute in segregation The quality attributes for architectural design consist of reliability, performance, security,
maintainability, flexibility, testability, portability, re-usability etc.
5. Identify the quality attributes sensitivity
The sensitivity of quality attributes achieved by making the small changes in the
architecture and find the sensitivity of the quality attribute which affects the performance.
The attributes affected by the variation in the architecture are known as sensitivity points.
Architectural styles for Software Design
The architectural styles that are used while designing the software as follows:
1. Data-centered architecture
The data store in the file or database is occupying at the center of the architecture. Store data is access continuously by the other components like an update, delete, add, modify
from the data store. Data-centered architecture helps integrity. Pass data between clients using the blackboard mechanism. The processes are independently executed by the client components.
This architecture is applied when the input data is converted into a series of manipulative components into output data.
A pipe and filter pattern is a set of components called as filters. Filters are connected through pipes and transfer data from one component to the next
component. The flow of data degenerates into a single line of transform then it is known as batch sequential.
3. Call and return architectures
This architecture style allows to achieve a program structure which is easy to modify.
Following are the sub styles exist in this category:
1. Main program or subprogram architecture
The program is divided into smaller pieces hierarchically. The main program invokes many of program components in the hierarchy that program
components are divided into subprogram.
2. Remote procedure call architecture
The main program or subprogram components are distributed in network of multiple computers.
The main aim is to increase the performance.
4. Object-oriented architectures
This architecture is the latest version of call-and-return architecture. It consist of the bundling of data and methods.
5. Layered architectures
The different layers are defined in the architecture. It consists of outer and inner layer. The components of outer layer manage the user interface operations. Components execute the operating system interfacing at the inner layer. The inner layers are application layer, utility layer and the core layer. In many cases, It is possible that more than one pattern is suitable and the alternate
architectural style can be designed and evaluated.
Component design introduction
A software component is a modular building block for the computer software.
Component is defined as a modular, deployable and replaceable part of the system which
encloses the implementation and exposes a set of interfaces.
Components view
The components has different views as follows:
1. An object-oriented view
An object-oriented view is a set of collaborating classes.
The class inside a component is completely elaborated and it consists of all the attributes
and operations which are applicable to its implementation.
To achieve object-oriented design it elaborates analysis classes and the infrastructure
classes.
2. The traditional view
A traditional component is known as module.
It resides in the software and serves three important roles which are control component, a
problem domain component and an infrastructure component.
A control component coordinate is an invocation of all other problem domain
components.
A problem domain component implements a complete function which is needed by the
customer.
An infrastructure component is responsible for function which support the processing
needed in the problem domain.
3. The Process related view
This view highlights the building system out of existing components.
The design patterns are selected from a catalog and used to populate the architecture.
Class-based design components
The principles for class-based design component are as follows:
Open Closed Principle (OCP) Any module in OCP should be available for extension and modification.
The Liskov Substitution Principle (LSP)
The subclass must be substitutable for their base class.
This principle was suggested by Liskov.
Dependency Inversion Principle (DIP)
It depends on the abstraction and not on concretion.
Abstraction is the place where the design is extended without difficulty.
The Interface Segregation Principle (ISP) Many client specific interfaces is better than the general purpose interface.
The Release Reuse Equivalency Principle (REP)
A fragment of reuse is the fragment of release.
The class components are designed for reuse which is an indirect contract between the
developer and the user.
The common closure principle (CCP) The classes change and belong together i.e the classes are packaged as part of design which
should have the same address and functional area.
The Common Reuse Principle (CRP) The classes that are not reused together should not be grouped together.
User Interface design
User interface design helps in successing most of the software.
It is part of the user and computer.
Good interface design is user friendly.
Types of user interface:
1. Command Interpreter Commands help the user to communicate with the computer system.
2. Graphical User Interfaces (GUI)
It is another approach to communicate with system.
It allows a mouse-based, window-menu-based systems as an interface.
The Golden Rules
The golden rules are known as interface design principles.
The golden rule are as follows:
1. Place the user in control
The interaction should be defined in such a way that the user is not forced to implement
unnecessary actions.
The technical internal details must be hidden from the casual user.
Design for the direct interaction with objects that appear on the screen.
2. Reduce the user's memory load
The user interface must be designed in such a way that it reduces the demands on the
user's short term memory.
Create the meaningful defaults value as an advantage for the average users in the start of
application.
There must be a reset option for obtaining the default values.
The shortcut should be easily remembered by the users.
The interface screen should be friendly to users.
3. Make the interface consistent
The system must allow the user to put task into meaningful context.
Consistency should be maintained for all the interaction.
Do not change the past system that is created by the user expectation unless there is a
good reason to do that.
User interface design issues
The user interface design consist of following four issues:
1. Response time of the system
Length and variability are the two important characteristic of the system response time.
2. User help facilities The user of each software system needs the help facility or the user manual for the smooth use of
the software.
3. Error information handling
Many error messages and warnings are created which irritate the users as they are not
meaningful. Only the critical problems should be handled.
Error message guidelines are as follows:
The language of error message should be described in plain language i.e easily
understandable for the users.
For recovering the error,useful advice should be provided.
The error message must have an audible or visual indications like beep, short flashing or
the special error color.
The error messages must indicate any negative result so that the user verifies it.
The wordings of message should not be blamed on the user.
4. Command labeling The commands and menu labeling must be consistent, easy to understand and learn.
WebApp Interface design
The principles for designing the WebApp are as follows:
1. Anticipation A WebApp should be designed so that it can anticipate the user's next move.
2. Communication
The interface must communicate the status of any activity initiated by the user.
3. Consistency Throughout the WebApp the use of navigation control, menus, icons, decorative parts should be
consistent.
4. Efficiency The design of WebApp and its interfaces must optimize the user's work efficiency and not the
efficiency of developer.
5. Flexibility The system must be flexible to accommodate the need of user.
6. Focus
The WebApp interface and the content present in it must focus on the users task.
7. Readability The presented information must be readable to all the users.
8. Learnability
A WebApp interface must be designed to minimize the learning time.
After learned, It is necessary to minimize the relearning when the WebApp is revisited.
9. Metaphors An interface uses an interaction metaphor that is easier to learn and use until the metaphor is
appropriate for the application and the user.
10. Maintain the integrity of work product A work product should be saved automatically so it does not lose an error message which has
occurred automatically.
Introduction to Testing
Testing is a set of activities which are decided in advance i.e before the start of
development and organized systematically.
In the literature of software engineering various testing strategies to implement the testing
are defined.
All the strategies give a testing template.
Following are the characteristic that process the testing templates:
The developer should conduct the successful technical reviews to perform the testing
successful.
Testing starts with the component level and work from outside toward the integration of
the whole computer based system.
Different testing techniques are suitable at different point in time.
Testing is organized by the developer of the software and by an independent test group.
Debugging and testing are different activities, then also the debugging should be
accommodated in any strategy of testing.
Difference between Verification and Validation
Verification Validation
Verification is the process to find whether the
software meets the specified requirements for
particular phase.
The validation process is checked whether the
software meets requirements and expectation
of the customer.
It estimates an intermediate product. It estimates the final product.
The objectives of verification is to check whether
software is constructed according to requirement
and design specification.
The objectives of the validation is to check
whether the specifications are correct and
satisfy the business need.
It describes whether the outputs are as per the
inputs or not.
It explains whether they are accepted by the
user or not.
Verification is done before the validation. It is done after the verification.
Plans, requirement, specification, code are
evaluated during the verifications.
Actual product or software is tested under
validation.
It manually checks the files and document.
It is a computer software or developed
program based checking of files and
document.
Strategy of testing
A strategy of software testing is shown in the context of spiral.
Following figure shows the testing strategy:
Unit testing Unit testing starts at the centre and each unit is implemented in source code.
Integration testing
An integration testing focuses on the construction and design of the software.
Validation testing Check all the requirements like functional, behavioral and performance requirement are validate
against the construction software.
System testing System testing confirms all system elements and performance are tested entirely.
Testing strategy for procedural point of view
As per the procedural point of view the testing includes following steps.
1) Unit testing
2) Integration testing
3) High-order tests
4) Validation testing
These steps are shown in following figure:
Strategy Testing Issues
Following are the issues considered to implement software testing strategies.
Specify the requirement before testing starts in a quantifiable manner.
According to the categories of the user generate profiles for each category of user.
Produce a robust software and it's designed to test itself.
Should use the Formal Technical Reviews (FTR) for the effective testing.
To access the test strategy and test cases FTR should be conducted.
To improve the quality level of testing generate test plans from the users feedback.
Test strategies for conventional software
Following are the four strategies for conventional software:
1) Unit testing
2) Integration testing
3) Regression testing
4) Smoke testing
1) Unit testing
Unit testing focus on the smallest unit of software design, i.e module or software
component.
Test strategy conducted on each module interface to access the flow of input and output.
The local data structure is accessible to verify integrity during execution.