SE Summary
SE Summary
software product
• Generic products :These are stand-alone systems that are produced by a
development organization and sold on the open market to any customer who is
able to buy them. Examples of this type of product include apps for mobile
devices, software for PCs such as databases, word processors, drawing
packages, and project management tools.
• Customized software These are systems that are commissioned by and
developed for a particular customer. A software contractor designs and
implements the software especially for that customer. Examples of this type of
software include control systems for electronic devices, systems written to
support a particular business process, and air traffic control systems.
• The critical distinction between these types of software is that, in generic
products, the organization that develops the software controls the software
specification, This means that if they run into development problems, they
can rethink what is to be developed.
• For custom products, the specification is developed and controlled by the
organization that is buying the software. The software developers must
work to that specification.
• Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system specification
through to maintaining the system after it has gone into use
• In this definition, there are two key phrases:
1-Engineering discipline Engineers make things work. They apply theories, methods,
and tools where these are appropriate. However, they use them selectively
2-All aspects of software production Software engineering is not just concerned with the
technical processes of software development. It also includes activities such as
software project management and the development of tools, methods, and theories to
support software development.
Essential attributes of good software
Product characteristic Description
Acceptability Software must be acceptable to the type of users for which it is designed.
This means that it must be understandable, usable, and compatible with
other systems that they use.
Dependability and Software dependability includes a range of characteristics including
security reliability, security, and safety. Dependable software should not cause
physical or economic damage in the event of system failure. Software has
to be secure so that malicious users cannot access or damage the system.
Efficiency Software should not make wasteful use of system resources such as
memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, resource utilization, etc.
Maintainability Software should be written in such a way that it can evolve to meet the
changing needs of customers. This is a critical attribute because software
change is an inevitable requirement of a changing business environment
Key Points:
Software process
A software process is a set of related activities that leads to the production of a software
system
Software process models
The waterfall model :This takes the fundamental process activities of
specification, development, validation, and evolution and represents them as
separate process phases such as requirements specification, software design,
implementation, and testing.
Incremental development :This approach interleaves the activities of
specification, development, and validation. The system is developed as a series
of versions (increments), with each version adding functionality to the previous
version
Integration and configuration: This approach relies on the availability of
reusable components or systems. The system development process focuses on
configuring these components for use in a new setting and integrating them into
a system.
The majority of practical software processes are based on a general model but often
incorporate features of other models. This is particularly true for large systems
engineering. For large systems, it makes sense to combine some of the best features of
all of the general processes.
You need to have information about the essential system requirements to design
a software architecture to support these requirements. You cannot develop this
incrementally. Subsystems within a larger system may be developed using
different approaches.
Waterfall model
The first published model of the software development process was derived from
engineering process models used in large military systems engineering (Royce 1970). It
presents the software development process as a number of stages, as shown in last
Figure. Because of the cascade from one phase to another, this model is known as the
waterfall model or software life cycle. The waterfall model is an example of a plan-driven
process. In principle at least, you plan and schedule all of the process activities before
starting software development.
Incremental development
Incremental development is based on the idea of developing an initial
implementation, getting feedback from users and others, and evolving the
software through several versions until the required system has been developed
Figure below . Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback across activities.
Incremental development has three major advantages over the waterfall model:
The cost of implementing requirements changes is reduced. The amount of
analysis and documentation that has to be redone is significantly less than is
required with the waterfall model.
It is easier to get customer feedback on the development work that has been
done. Customers can comment on demonstrations of the software and see how
much has been implemented. Customers find it difficult to judge progress from
software design documents.
Early delivery and deployment of useful software to the customer is possible,
even if all of the functionality has not been included. Customers are able to use
and gain value from the software earlier than is possible with a waterfall process
Process activities types
Software specification: Software specification or requirements engineering is
the process of understanding and defining what services are required from the
system.
Software design and implementation: The implementation stage of software
development is the process of developing an executable system for delivery to
the customer
Software validation: Software validation or, more generally, verification and
validation (V & V) is intended to show that a system both conforms to its
specification and meets the expectations of the system customer.
Software evolution: The flexibility of software is one of the main reasons why
more and more software is being incorporated into large, complex systems
Prototyping
A prototype is an early version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its possible
solutions. Rapid, iterative development of the prototype is essential so that costs are
controlled and system stakeholders can experiment with the prototype early in the
software process.
A software prototype can be used in a software development process to help anticipate
changes that may be required:
1. In the requirements engineering process, a prototype can help with the elicitation
and validation of system requirements
2. In the system design process, a prototype can be used to explore software
solutions and in the development of a user interface for the system.
Process improvement
The stages in this process are:
1) Process measurement You measure one or more attributes of the software
process or product. These measurements form a baseline that helps you decide
if process improvements have been effective. As you introduce improvements,
you re-measure the same attributes, which will hopefully have improved in some
way.
2) Process analysis: the current process is assessed, and process weaknesses
and bottlenecks are identified. Process models (sometimes called process maps)
that describe the process may be developed during this stage. The analysis may
be focused by considering process characteristics such as rapidity and
robustness.
3) Process change : Process changes are proposed to address some of the
identified process weaknesses. These are introduced, and the cycle resumes to
collect data about the effectiveness of the changes.
Agile methods
In the 1980s and early 1990s, there was a widespread view that the best way to
achieve better software was through careful project planning, formalized quality
assurance, use of analysis and design methods supported by software tools, and
controlled and rigorous software development processes.
This plan-driven approach was developed for software developed by large
teams, working for different companies. Teams were often geographically
dispersed and worked on the software for long periods of time. An example of
this type of software is the control systems for a modern aircraft, which might
take up to 10 years from initial specification to deployment. Plan- driven
approaches involve a significant overhead in planning, designing, and
documenting the system.
Rapid software development became known as agile development or agile
methods. These agile methods are designed to produce useful software quickly.
The philosophy behind agile methods is reflected in the agile manifesto issued by
the leading developers of these methods.
User stories
Software requirements always change. To handle these changes, agile methods
do not have a separate requirements engineering activity. Rather, they integrate
requirements elicitation with development. To make this easier, the idea of “user
stories” was developed where a user story is a scenario of use that might be
experienced by a system user.
Refactoring
A fundamental precept of traditional software engineering is that you should design for
change. That is, you should anticipate future changes to the software and design it so
that these changes can be easily implemented. Extreme programming, however has
discarded this principle on the basis that designing for change is often waste effort. It
isn’t worth taking time to add generality to a program to cope with change Often the
changes anticipated never materialize, or completely different change requests may
actually be made.
Test-first development
•Extreme Programming developed a new approach to program testing to address
the difficulties of testing without a specification. Testing is automated and is
central to the development process, and development cannot proceed until all
tests have been successfully executed.
It can be difficult to introduce agile methods into large companies for a number of
reasons:
• Project managers who do not have experience of agile methods may be reluctant
to accept the risk of a new approach
• Large organizations often have quality procedures and standards that all projects
are expected to follow
• Agile methods seem to work best when team members have a relatively high skill
level
• There may be cultural resistance to agile methods, especially in those
organizations that have a long history of using conventional systems engineering
processes.
Key Points