SOFTWARE ENGINEERING &
PROJECT MANAGEMENT
MODULE 1: INTRODUCTION
SOFTWARE PROCESSES
INTRODUCTION
• What is software?
A program is a set of instructions that performs a specific task.
Software is Computer programs with associated documentation and
configuration data.
• Depending on the context of its operation different types of software
require different approaches for development. It is also possible that
software can fail. The failure of software could be due to:
1) Increase in demand and
2) Low expectation
• Why do you need documentation?
For enabling other users to read/ use the program you have written.
• What is a Function?
A reusable piece of code that performs a specific task within a program.
• What is Engineering?
Developing products using well-defined, scientific principles and
methods.
• What is Software Engineering?
It is an engineering discipline concerned with all aspects of software
production. The outcome of the process is efficient and reliable
software product.
• What is a software product?
Software when made for a specific requirement.
• What are the attributes of good software? Good software should
deliver the required functionality and performance to the user and
should be maintainable, dependable, and usable.
• What are the fundamental software engineering activities?
1. Software specification
2. software development,
3. software validation, and
4. software evolution.
• What are the key challenges facing software engineering?
1. Coping with increasing diversity,
2. demands for reduced delivery times, and
3. developing trustworthy software.
• What is the difference between software engineering and computer
science?
1.
2.
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.
Types of software products
• Software engineers are concerned with developing software products (i.e.,
software which can be sold to a customer). There are two kinds of software
products:
1. 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 software for PCs such as databases,
word processors, drawing packages, and project-management tools.
2. Customized (or bespoke) products A software contractor develops 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.
• In generic products, the organization that develops the software
controls the software specification.
• For custom products, the specification is usually developed and
controlled by the organization that is buying the software.
Software engineering
• 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.
1. Engineering discipline: Engineers make things work. They apply
theories, methods and appropriate tools. They always try to discover
solutions to problems under organizational and financial conditions.
2. All aspects of software production: not just technical process but
also software project management, development of tools, methods
and theories to support software production.
Why is Software engineering important?
1. More and more, individuals and society rely on advanced software
systems. We need to be able to produce reliable and trustworthy
systems economically and quickly.
2. For most types of systems, the majority of costs are the costs of
changing the software after it has gone into use.
Software process
The systematic approach that is used in software engineering is sometimes called
a software process. A software process is a sequence of activities that leads to the
production of a software product. There are four fundamental activities that are
common to all software processes. These activities are:
1. Software specification, where customers and engineers define the software that
is to be produced and the constraints on its operation.
2. Software development, where the software is designed and programmed.
3. Software validation, where the software is checked to ensure that it is what the
customer requires.
4. Software evolution, where the software is modified to reflect changing customer
and market requirements.
Software engineering diversity
There are no universal software engineering methods and techniques
that are suitable for all systems and all companies. Perhaps the most
significant factor in determining which software engineering methods
and techniques are most important is the type of application that is
being developed. There are many different types of application including:
1. Stand-alone applications These are application systems that run on a
local computer, such as a PC. They include all necessary functionality and
do not need to be connected to a network. Examples of such applications
are office applications on a PC, CAD programs, photo manipulation
software, etc.
2. Interactive transaction-based applications These are applications
that execute on a remote computer and that are accessed by users
from their own PCs or terminals .
This class of application also includes business systems, where a
business provides access to its systems through a web browser or
special-purpose client program and cloud-based services, such as mail
and photo sharing.
3. Embedded control systems These are software control systems that
control and manage hardware devices.
Examples of embedded systems include the software in a mobile (cell)
phone, software that controls anti-lock braking in a car, and software in
a microwave oven to control the cooking process.
4. Batch processing systems These are business systems that are
designed to process data in large batches.
Examples: Periodic billing systems, such as phone billing systems, and
salary payment systems.
5. Entertainment systems These are systems that are primarily for
personal use and which are intended to entertain the user. Ex: Games.
6. Systems for modeling and simulation These are systems that are
developed by scientists and engineers to model physical processes or
situations.
7. Data collection systems These are systems that collect data from
their environment using a set of sensors and send that data to other
systems for processing.
8. Systems of systems These are systems that are composed of a
number of other software systems. Ex: spreadsheet program
embedded in other system.
Software engineering ethics
Software engineering is carried out within a social and legal framework
that limits the freedom of people working in that area.
Along with technical skills, You must also behave in an ethical and
morally responsible way if you are to be respected as a professional
engineer.
1. Confidentiality You should normally respect the confidentiality of your
employers or clients irrespective of whether or not a formal confidentiality
agreement has been signed.
2. Competence You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your competence.
3. Intellectual property rights You should be aware of local laws governing
the use of intellectual property such as patents and copyright. You should be
careful to ensure that the intellectual property of employers and clients is
protected.
4. Computer misuse You should not use your technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine, say) to extremely serious (dissemination
of viruses or other malware).
Confidentiality is an Ethical Obligation
• Even if there is no formal Non-Disclosure Agreement (NDA), professionals
should not disclose sensitive information.
• Trust and integrity are crucial in any professional relationship.
• Example:
A software developer working on a proprietary algorithm for a company
should not share its details with competitors, even if no official NDA is
signed.
Protecting Business Interests
• Companies and clients often share business strategies, trade secrets,
financial data, and customer information with employees or consultants.
• Leaking such information can cause financial loss, reputational damage, or
legal consequences.
• Example:
An accountant should not reveal a client's tax strategies or financial
struggles to outsiders, as it could harm their business.
Legal and Professional Consequences
Breaching confidentiality can result in lawsuits, loss of credibility, and
professional penalties.
Example:
A doctor should not disclose a patient's medical history to unauthorized
individuals, even if the patient has not signed a formal confidentiality
agreement.
Exceptions to Confidentiality
Confidentiality may be broken only in legal or ethical situations, such as:
If required by law (e.g., court orders, criminal investigations).
If disclosure is necessary to prevent harm (e.g., reporting fraud or security breaches).
Example:
A cybersecurity professional discovers a severe security vulnerability in a
company's system. If the company refuses to act and public data is at risk,
they may have an ethical obligation to report it.
Competence
1. Honesty About Skills and Knowledge
• Professionals should accurately represent their qualifications, certifications, and experience.
• Misrepresenting expertise can lead to poor-quality work, legal consequences, or harm to others.
Example:
• A software developer claims to be an expert in machine learning despite having no experience and
takes on an AI-based project. As a result, the system fails, causing financial losses to the company.
2. Ethical Responsibility
Accepting work beyond your capability can lead to incorrect solutions, defects, or safety
hazards.
It is unethical to take on work you know you cannot perform effectively.
Example:
•A civil engineer who has only designed small residential buildings accepts a contract for a
high-rise commercial complex without proper knowledge of large-scale structural
requirements.
•If the building collapses due to poor design, lives may be at risk.
3. Professional Integrity
•A responsible professional acknowledges their limitations and seeks guidance or training when necessary.
•They should refer work to someone more qualified if they lack the necessary skills.
Example:
•A doctor trained in general medicine should not perform a complex surgery unless they are a certified
surgeon. Instead, they should refer the patient to a qualified specialist.
4. Quality Assurance and Public Trust
• Work done incompetently can damage reputation, customer trust, and industry standards.
• Professionals must ensure they meet the necessary qualifications before taking on work.
Example:
• A cybersecurity consultant who has never worked with large enterprise systems claims to be an expert in
network security. Their failure to implement proper security measures leads to a major data breach.
What Should You Do Instead?
• Assess your competence before accepting a task.
• Seek training or upskilling in areas where you lack expertise.
• Collaborate with experts when facing complex problems beyond your
knowledge.
• Be transparent with clients or employers about your skills.
Understanding Intellectual Property Rights
• Intellectual property (IP) refers to creations of the mind that have
legal protection, such as:
• Patents – Protect inventions and innovations.
• Copyright – Protects creative works (e.g., software, books, music).
• Trademarks – Protects brand names and logos.
• Trade Secrets – Confidential business information (e.g., formulas,
algorithms).
• Example:
A software engineer working for a company should not copy and sell
the company’s source code, as it is protected by copyright laws.
Awareness of Local Laws
• Different countries have different laws governing intellectual
property.
• Professionals must ensure compliance with relevant laws in their
region.
• Example:
In the USA, software algorithms can be patented, whereas in some
countries, they cannot. A developer working internationally must be
aware of these legal differences.
Computer misuse
• It can range from minor infractions (like using work computers for personal
activities) to serious cybercrimes (such as hacking or spreading malware).
Examples of Computer Misuse
a) Minor Misuse (Unethical but not Criminal)
• Playing games or browsing social media on a work computer during office
hours.
• Using company resources (e.g., printers, software) for personal projects.
• Accessing files or data without permission.
• Example:
An employee using an office laptop to stream movies during work hours.
b) Serious Misuse (Illegal & Criminal Activities)
• Hacking into systems to steal, modify, or delete data.
• Spreading malware, ransomware, or viruses that damage systems.
• Phishing or identity theft to steal sensitive information.
• Denial-of-Service (DoS) attacks to disrupt services.
• Example:
A hacker gaining unauthorized access to bank servers and stealing
customer data.
Consequences of Computer Misuse
• Legal penalties (fines, imprisonment under cybercrime laws).
• Job termination or disciplinary actions.
• Loss of trust and damage to professional reputation.
• Financial losses for companies and individuals
Key Sections of the Document
The image contains the Software Engineering Code of Ethics and
Professional Practice, created by the ACM/IEEE-CS Joint Task Force on
Software Engineering Ethics and Professional Practices. It outlines ethical
principles that software engineers must follow to ensure professionalism,
integrity, and responsibility in their work.
1. Preamble
• Explains the purpose of the ethical code, which is to guide software
engineers in ethical decision-making.
• Highlights the importance of balancing aspirations and details in ethical
guidelines.
• Emphasizes the commitment of software engineers to producing reliable,
safe, and ethical software.
Eight Ethical Principles
Public Interest
Software engineers must act in the best interest of the public and ensure their work
does not harm society.
Client and Employer
Engineers should prioritize their clients' and employers' interests while ensuring
ethical practices and alignment with public welfare.
Product
Ensure software products and modifications meet high professional standards,
including safety, security, and functionality.
Judgment
Maintain integrity and independence when making professional decisions. Avoid
conflicts of interest.
Management
Software engineering managers and leaders should promote an ethical approach to
software development and project management.
Profession
Engineers should work to uphold the integrity and reputation of the software
engineering profession.
Colleagues
Support and respect fellow engineers in the workplace. Promote teamwork and
fairness.
Self
Engage in lifelong learning to stay updated with industry developments and promote
ethical practices in software engineering.
Case
studies
To illustrate software engineering concepts, we use examples from three
different types of systems:
1. An embedded system This is a system where the software controls a
hardware device and is embedded in that device. Issues in embedded systems
typically include physical size, responsiveness, power management, etc. The
Example is a software system to control a medical device.
2. An information system This is a system whose primary purpose is to
manage and provide access to a database of information. Issues in information
systems include security, usability, privacy, and maintaining data integrity. The
example : a medical records system.
3. A sensor-based data collection system This is a system whose primary
purpose is to collect data from a set of sensors and process that data in some
way. The key requirements of such systems are reliability, even in hostile
environmental conditions, and maintainability. example: a wilderness weather
station.
1. Insulin pump control system:
• The insulin pump is a medical embedded system designed to simulate the
pancreas by automating insulin delivery for diabetes patients.
• The software collects blood sugar levels from a sensor and controls a
miniature pump that delivers the required dose of insulin.
Diabetes and the Need for Automation
• Diabetes is a condition where the pancreas fails to produce enough insulin,
a hormone that regulates blood sugar levels.
• Traditional treatment involves manual insulin injections based on blood
sugar readings.
• However, insulin requirements fluctuate based on previous injections,
making manual control prone to errors.
• Incorrect insulin levels can lead to:
Hypoglycemia (low blood sugar) → Can cause brain malfunction, unconsciousness, or
death.
Hyperglycemia (high blood sugar) → Can cause long-term organ damage (eyes, kidneys,
heart, etc.).
Automated Insulin Delivery System
• Advances in miniaturized sensors enable automated systems that
monitor blood sugar and deliver insulin as needed.
How it works:
• A micro-sensor embedded in the body measures blood sugar levels.
• The data is sent to the pump controller.
• The controller calculates the required insulin dosage.
• The pump injects insulin via a needle.
• The pump delivers insulin in units, where each pulse from the controller
corresponds to one unit of insulin.
Activity model of insulin pump
System Safety and Reliability
• The insulin pump is a safety-critical system since failures can be lifethreatening.
Two key high-level requirements:
• The system must be available to deliver insulin when required.
• The system must be reliable and accurate, ensuring the correct insulin dosage is
delivered.
Conclusion:
• Automated insulin pumps improve diabetes management, reducing human
error and health risks.
• The system must be fail-safe, ensuring continuous availability and accurate
insulin delivery.
2. MHC-PMS (Mental Health Care-Patient
Management System)
The case study describes the Mental Health Care-Patient Management
System (MHC-PMS), a medical information system designed to
support the management of patients with mental health problems in
specialized clinics.
Purpose:
MHC-PMS maintains patient information related to mental health
treatments. It allows clinicians to record and manage data on patients,
including personal details, medical conditions, treatments, and
consultations.
System Functionality:
• Centralized Database: The system uses a centralized database to
store patient information. It can be accessed from various locations,
including local medical practices or community centers, where
patients attend regular checkups.
• Offline Functionality: The system can operate without network
connectivity by downloading local copies of patient records, ensuring
that it can still be used in areas without secure network access.
• Integration: Although it doesn’t manage other medical conditions,
the MHC-PMS can exchange data with other clinical systems to
provide a comprehensive view of the patient's health.
Goals:
1. Management Information: The system helps health service managers assess performance
against targets.
2. Support for Medical Staff: It provides timely information to help doctors and clinicians in
treating mental health patients.
3.
Challenges Addressed:
The system addresses the specific challenges of mental health patients, who may be disorganized,
miss appointments, or have unpredictable behavior. Some patients may also pose a risk to
themselves or others, so the system tracks such cases and ensures appropriate legal and medical
actions are taken, especially in cases where patients are "sectioned" (compulsorily detained).
Users:
1. Medical Users: Doctors, nurses, and health visitors who interact with the system to provide
treatment and monitor patient progress.
2. Non-Medical Users: Receptionists, medical records staff, and administrative staff who manage
appointments, patient records, and generate reports.
Key Features:
1. Care Management: Clinicians can create and update patient records, view medical
histories, and summarize patient conditions for easy access during consultations.
2. Patient Monitoring: The system monitors patient records and issues warnings for
missed appointments, overdue treatments, or other critical alerts (e.g., suicidal or
dangerous behavior).
3. Reporting: Generates administrative reports such as the number of patients treated,
costs of medications, and other relevant statistics for health authorities.
Legal and Privacy Concerns:
1. Data Protection: The system must comply with laws protecting patient confidentiality
and privacy, ensuring that only authorized personnel can access sensitive information.
2. Mental Health Laws: The system also needs to comply with laws regarding the
compulsory detention of patients who may be a danger to themselves or others,
ensuring that these decisions are legally documented.
Safety-Critical Nature:Given that some mental illnesses can lead
patients to be suicidal or dangerous, the system is designed to alert
medical staff about such risks. It must be reliable and always available
to ensure patient safety, despite challenges related to maintaining data
privacy and system availability.
System Design Challenges:Balancing privacy and availability is a core
challenge. While privacy is easier to maintain with a single data copy,
multiple copies are needed to ensure availability, particularly in case of
network failure or server issues.
Case Study 3: A Wilderness Weather Station
Overview
This case study describes a weather information system designed to
monitor climate change and improve weather forecasting in remote
wilderness areas. The government deploys several hundred
automated weather stations to collect and transmit weather data.
Key Components of the System
1.Weather Station System
• Installed in remote areas to collect weather data (temperature, pressure,
wind speed, rainfall, etc.).
• Performs basic data processing before transmitting the data.
2. Data Management and Archiving System
• Receives data from all weather stations.
• Processes and analyzes the data.
• Archives the data for retrieval by weather forecasting systems.
3. Station Maintenance System
• Communicates with the weather stations via satellite.
• Monitors the health of the system and reports issues.
• Updates software remotely and can control weather stations if needed.
Purpose and Importance
• Climate Monitoring – Helps study climate change trends.
• Weather Forecasting – Provides data for more accurate weather predictions.
• Remote System Management – Ensures that stations function properly without
requiring physical maintenance in difficult-to-reach areas.
• UML package symbols are used to
represent each system as a
collection of components.
• UML stereotype <<system>>
labels the separate systems.
• The connections between systems
indicate an exchange of
information but detailed
interactions are not defined at
this stage.
Weather Station System Functionality
1.Weather Data Collection
• Measures weather parameters (wind speed, temperature, pressure, rainfall, etc.).
• Software in each station controls the instruments and collects periodic readings.
2.Data Processing and Transmission
• Observations are taken at frequent intervals (e.g., temperatures measured every minute).
• Due to limited satellite bandwidth, the station aggregates and processes data before
transmission.
• If communication fails, the station stores data locally until a connection is restored.
3.Self-Sufficiency and Power Management
• Stations are battery-powered and self-contained (no external power or network cables).
• Uses solar or wind power to charge batteries.
• The software monitors power levels and shuts down generators in extreme weather
conditions.
4.System Maintenance and Fault Handling
• Monitors instruments, power, and communication hardware.
• Reports faults to the management system for remote troubleshooting.
• Allows for remote software updates and switches to backup instruments if failures occur.
Complexity of the Software
• The core function (data collection) is simple.
• However, the system needs complex software for:
• Power and resource management
• Fault detection and self-repair
• Remote reconfiguration and software updates
• Must withstand extreme environmental conditions and potential
damage by animals.
Software Processes
A software process is a structured set of activities required to develop a
software system.
1. Specification – defining what the system should do;
2. Design and implementation – defining the organization of the
system and implementing the system;
3. Validation – checking that it does what the customer wants;
4. Evolution – changing the system in response to changing customer
needs
• Sometimes, software processes are categorized as either plan-driven
or agile processes.
• Plan-driven processes are processes where all of the process activities
are planned in advance and progress is measured against this plan.
• In agile processes, planning is incremental and it is easier to change
the process to reflect changing customer requirements.
Software Process Models:
A software process model is a simplified representation of a software process.
The passage discusses three generic software development models that are
frameworks for software processes, not definitive descriptions. These models help
explain various approaches to software development and can be adapted to create
specific engineering processes. Here's a summary of the three models:
1. Waterfall Model: This model divides the software development process into
distinct phases like requirements specification, design, implementation, and
testing. Each phase is done sequentially, one after another.
2. Incremental Development: This model overlaps specification, development, and
validation activities. The system is built in small, functional increments, with each
version adding more features to the system.
3. Reuse-Oriented Software Engineering: This approach focuses on integrating preexisting reusable components into the system rather than developing new
components from scratch.
These models are often combined for large systems. For example, the overall
system architecture may be developed using the waterfall model, while individual
components (like user interfaces) may follow an incremental approach.
The waterfall Model
• The waterfall model, first published by Royce in 1970, is derived from
general system engineering processes.
• It is a sequential process where each phase flows into the next,
resembling a waterfall.
• This model is a plan-driven approach, meaning all activities must be
planned and scheduled before beginning work on them.
• It is often referred to as the software life cycle due to its structured,
linear progression.
The waterfall model consists of several key stages that reflect the core activities of software
development:
1. Requirements Analysis and Definition: System requirements, services, constraints, and goals are
established through consultations with users, resulting in a detailed system specification.
2. System and Software Design: This stage involves defining the system architecture and allocating
requirements to hardware or software. Software design identifies system abstractions and their
relationships.
3. Implementation and Unit Testing: The design is turned into code, and each unit of the software is
tested to ensure it meets its specification.
4. Integration and System Testing: The individual software components are integrated and tested as
a complete system to verify that it meets all requirements.
5. Operation and Maintenance: The system is deployed and used, with maintenance involving fixing
errors, improving system components, and adding new features as needed.
While each phase produces documents that are typically approved before moving to the next phase,
in practice, these stages often overlap, with feedback and modifications occurring throughout.
Iterations may be costly, so parts of the development are sometimes frozen early, which can result in
the system not fully meeting user needs or creating a poorly structured system. During the final
phase, ongoing maintenance may require revisiting earlier stages to address issues and adapt the
system.
Advantages of the Waterfall Model:
1.Simple and Easy to Understand: The waterfall model is straightforward, with
clear, distinct phases that are easy to follow and manage.
2.Structured Approach: Since each phase is well-defined, it provides a disciplined,
systematic approach to software development.
3.Clear Documentation: Documentation is created at every phase, making it easier
to track progress and provide detailed records of the development process.
4.Easy to Manage: With distinct phases and deliverables, project management
becomes more straightforward. It is easier to monitor progress and allocate
resources.
5.Well-Suited for Small Projects: If the requirements are clear and unlikely to
change, the waterfall model works well for small or less complex projects.
6.Predictable Timelines and Budgets: Since all requirements and design are
defined upfront, it’s easier to estimate time, cost, and resources.
Disadvantages of the Waterfall Model:
1. Inflexibility: Once a phase is completed, it's difficult and costly to go back and make changes. This
makes it unsuitable for projects where requirements may evolve during development.
2. Assumes Clear Requirements: The model assumes that all requirements are well understood at
the beginning, which is often not the case in complex or evolving projects.
3. Late Testing: Testing is done only after development, which can lead to discovering issues late in
the process when they are more costly and difficult to fix.
4. Customer Feedback Delay: Since the product is developed in stages and delivered at the end,
customer feedback is only gathered after completion, which might result in a product that doesn't
fully meet user needs.
5. Risk of Overlooking Requirements: The assumption that requirements won’t change may lead to
overlooking new needs or problems that arise during the development process.
6. Not Ideal for Large or Complex Projects: The waterfall model becomes challenging to apply in
larger projects where there are frequent changes, unforeseen challenges, or unclear
requirements.
Incremental development
Incremental development involves creating an initial version of a system,
exposing it to user feedback, and evolving it through several iterations until
the final product is complete. Unlike the waterfall model, specification,
development, and validation happen simultaneously with rapid feedback.
This approach is common in agile methodologies and is more suited for
business, e-commerce, and personal systems.
Key benefits include:
1.Reduced cost for accommodating changes: Changes to customer
requirements are easier and cheaper to implement.
2.Early customer feedback: Customers can review and comment on working
versions of the software, ensuring it meets their needs early on.
3.Faster delivery: Useful software can be delivered earlier, allowing
customers to gain value before the full system is finished.
challenges:
1.Lack of visibility: Managers might find it difficult to track progress
because regular documentation for every increment can be costly.
2.Degraded system structure: As new increments are added, the
system may become harder to maintain unless regular refactoring is
done.
• For large, complex systems, incremental development can be
problematic, especially if different teams work on various parts. A
stable architecture and clear team responsibilities must be planned
ahead. Additionally, incremental deployment is not always feasible if
it disrupts normal business operations.
Reuse-oriented software engineering
Reuse-oriented software engineering focuses on reusing existing
software components rather than developing everything from
scratch. While informal reuse has always occurred, modern
development processes formally integrate reuse by relying on a large
base of reusable software components and frameworks.
The process typically includes these stages:
1.Component Analysis: The requirements are reviewed, and existing
components that meet some of the needs are identified.
2.Requirements Modification: Requirements are adjusted based on
the available components. If needed, the component search is
repeated to find alternatives.
3. System Design with Reuse: The system framework is designed to
incorporate reusable components, and new software is developed if no
suitable components are available.
4. Development and Integration: New software is developed, and the
reusable components or COTS (Commercial Off-the-Shelf) systems are
integrated.
There are three types of components commonly used:
1.Web services for remote invocation.
2.Object collections integrated with frameworks like .NET or J2EE.
3.Standalone software systems configured for specific environments.
Advantages:
• Reduces development time, cost, and risks by reusing existing
software.
• Leads to faster software delivery.
Disadvantages:
• Requirement compromises may occur, leading to systems that don’t
fully meet user needs.
• Loss of control over system evolution, as updates to reusable
components are not managed by the developing organization.
Software Process Activities
Requirements engineering process
• Requirements engineering process consists of the following activities:
1. Feasibility study – Technical and Financial feasibility of the project needs
to be considered.
2. Requirements elicitation and analysis – Expectation from the system. The
functionalities that the system is expected to provide.
3. Requirements specification – Defining requirements for every activity
performed by the user or set of users and the expected outcome for each of
these activities.
4. Requirements validation – Checking validity of the requirements.
Verifying if the requirements specification contains the functionalities that
the system is expected to perform
• Once the feasibility study has been completed a feasibility report is
generated.
• requirements elicitation and analysis, requirements specification and
requirements validation are iterative activities.
• The requirements specification activity gives the complete user and
system requirements.
• The requirements validation process checks if the system performs the
required functions and the requirement specification covers all
functionalities to be provided by the system.
• The outcome of each activity is an input to the requirements document
Software design and implementation
• Each of these activities have a set of process activities to be carried
out.
• major aim of this phase of software development is to design a
software structure that realises the specification as given by the
requirements specification document.
• Design activities involve Architectural design, interface design and
component design.
• The system architecture and its components need to be defined and
specified as a part of architectural design.
• The interface design involves the specification and working of
interfaces for enables inter and intra component communication.
Implementation Translate this structure into an executable program.
This requires the use of a programming language.
Software validation
• Validating the software involve checking for conformation of the
system to its specification.
• This also involves checking and review processes and system testing.
• System testing involves executing the system with test cases.
• The system testing involves Component testing and acceptance
testing.
• Component testing involves testing of each component that is used to
build the software.
• The interfaces between the components and the working of
components with the existing system code needs to be tested.
• The process activities involved in testing and its iterations are shown
in Fig 5.
• Every individual component is tested and then system is tested as a
whole.
• Acceptance testing is done to determine if the system is functioning
well in the domain of its application.
• testing is carried out throughout the development process.
• As and when the requirements specification is complete the acceptance
test plan is also parallely written because the acceptance testing involves
testing of the software in its working domain.
• The test plan gets its input from both requirements specification as well as
system specification activities.
• The system integration test plan is an output of system specification and
design.
• Workings of individual components, testing for interfaces between them
are all a part of system integration testing.
• Once the detailed design is available the sub system integration test plan is
also drafted.
• Later on the tests are accomplished by making use of the test plan. This is
also called as V-model for test plan driven software development process.
Software Evolution
• software is inherently flexible and can change. As requirements
change through changing business circumstances, the software that
supports the business must also evolve and change.
• Fig 7 depicts the activities involved in software evolution.
• Existing system is continuously assessed based on the system
requirements.
• If any change has been proposed the system needs to be modified
and a new system is then released.
• This is an iterative process and continues until the required outcome
has been obtained.
Coping with Change
There are two related approaches that may be used to reduce the costs of
rework:
1. Change avoidance, where the software process includes activities that can
anticipate possible changes before significant rework is required. For example, a
prototype system may be developed to show some key features of the system to
customers. They can experiment with the prototype and refine their requirements
before committing to high software production costs.
2. Change tolerance, where the process is designed so that changes can be
accommodated at relatively low cost. This normally involves some form of
incremental development. Proposed changes may be implemented in increments
that have not yet been developed. If this is impossible, then only a single increment
(a small part of the system) may have to be altered to incorporate the change.
• System prototyping is a development approach where a working version
of the system, or part of it, is created quickly to validate customer
requirements and test design decisions. This allows users to interact with
the system before full delivery, helping refine their needs and reduce the
likelihood of post-delivery requirement changes. By enabling early
feedback, it helps avoid changes later in the process.
• Incremental delivery involves delivering parts of the system (increments)
to the customer for feedback and testing. This approach supports both
change avoidance and tolerance by preventing early, full commitment to
requirements. It allows for changes to be incorporated into future
increments with minimal cost, making the system more adaptable to
evolving needs.
The process of prototype development
Prototyping
• A prototype is an initial version of a software system used to demonstrate
concepts, test design options, and explore potential solutions. Rapid, iterative
development of the prototype is key to controlling costs and allowing early
experimentation. Prototypes are used in:
1. Requirements Engineering: They help elicit and validate system requirements.
2. System Design: They explore software solutions and support user interface
design.
• Prototypes allow users to interact with the system, leading to new ideas and the
identification of system strengths, weaknesses, and errors in requirements.
• They help refine system specifications based on user feedback.
• Prototypes also check the feasibility of design options, such as database structures,
and are crucial for developing user interfaces, where textual descriptions are
insufficient.
• The objectives of prototyping should be clearly defined from the start, such as
validating requirements, testing feasibility, or developing the user interface.
To keep costs low and speed up delivery, some functionality and nonfunctional requirements (like response time or error handling) may be
excluded from the prototype. The prototype's evaluation stage should
involve user training and a plan based on the prototype’s objectives, as
users may uncover errors once they start using the system.
However, there are challenges with prototyping, such as:
1.Prototypes may not be used like the final system, affecting feedback
accuracy.
2.Lack of typical user involvement, insufficient training, or slow response
times can distort the evaluation process.
3.Developers might be pressured to deliver "throwaway" prototypes, but
this can lead to issues like:
• Ignored non-functional requirements.
• Poor documentation for future maintenance.
• Degraded system structure and high maintenance costs.
Incremental delivery
• Incremental delivery is a software development approach where the
system is delivered in parts (increments) to the customer, who deploys
them in an operational environment. The process involves customers
prioritizing system services, with the most important services
implemented and delivered first. Each increment is developed and
delivered sequentially, with detailed requirements defined for the first
increment. Customers can use the early increments to clarify their
requirements for later ones, and as new increments are delivered, the
system functionality improves.
Advantages of incremental delivery:
1. Customers can use early increments as working prototypes, which helps
refine future requirements without re-learning.
2. The system provides value early by delivering the most critical
requirements first, allowing immediate use.
3. It maintains flexibility, making it easier to incorporate changes during
development.
4. Prioritizing and delivering high-priority services first ensures they receive
the most testing and are well validated.
Incremental delivery has several challenges:
1. Common Facilities: Identifying shared facilities needed by all increments can be
difficult since requirements are defined incrementally.
2. Replacement Systems: Users may be unwilling to use an incomplete new system,
making it hard to gather useful feedback.
3. Specification Conflicts: Incremental delivery conflicts with traditional
procurement models, where a complete system specification is required upfront,
complicating contract agreements.
• For very large systems, embedded systems, or critical systems where safety and
security are paramount, incremental delivery may not be ideal.
• These systems may require a more detailed upfront analysis. To address these
issues, an iterative prototype development approach can be used, allowing
experimentation with system requirements and design before finalizing them.
Boehm’s spiral model
The Spiral Model, proposed by Boehm in 1988, is a risk-driven software process
framework that represents the software development process as a spiral, with
each loop corresponding to a phase of the project. Unlike traditional models, it
emphasizes risk management and allows for iterative development,
accommodating changes throughout the process. Each loop in the spiral consists
of four key phases:
1.Objective Setting: Define specific objectives for the phase, identify constraints,
and create a management plan, including risk identification.
2.Risk Assessment and Reduction: Analyze and reduce project risks, such as by
creating prototypes if requirements are uncertain.
3.Development and Validation: Select an appropriate development model based on
identified risks (e.g., prototyping, formal transformations, or waterfall).
4.Planning: Review the project, decide if another loop is necessary, and plan for the
next phase.
• The spiral model explicitly integrates risk management throughout the process,
aiming to minimize project risks, such as schedule delays, cost overruns, or
technical uncertainties. This framework allows for ongoing adjustments based on
emerging risks, ensuring that the software evolves in response to challenges.
Advantages of the Spiral Model:
1.Risk Management: Emphasizes early and continuous risk identification and
mitigation.
2.Iterative Development: Allows for incremental development and frequent
refinements.
3.Flexibility: Adaptable to changing requirements and evolving needs.
4.Customer Feedback: Frequent feedback from customers ensures the
system meets their needs.
5.Continuous Improvement: Each iteration improves the system based on
ongoing learning.
6.Clear Planning: Transparent planning and documentation in each phase.
Disadvantages of the Spiral Model:
1.Complexity: Can be difficult to manage, especially for smaller projects.
2.High Cost: Requires significant resources and time due to multiple
iterations.
3.Requires Expertise: Needs skilled professionals for effective risk
management.
4.Not Ideal for Small Projects: Overkill for less complex projects with welldefined requirements.
5.Difficult to Measure Progress: Progress can be hard to track in early
stages.
6.Unclear End-Point: Continuous iterations may lead to uncertainty about
project completion.