Software Engineering

software engineering is a discipline whose aim is the production of fault-free

software, delivered on time and within budget, that satisfies the client’s needs.
Economic aspect
 One reason is the cost of introducing new technology into an organization.
 A second reason why the economics of software engineering may dictate that
CT old be retained is the maintenance consequence.
Maintenance aspects
1. Requirements phase: The concept is explored and refined, and the client’s
requirements are elicited.
2. Analysis (specification) phase. The client’s requirements are analysed and
presented in the form of the specification document, “what the product is supposed
to do. At the end of this phase, a plan is drawn up, the software project management
plan, describing the proposed software development in full detail.

3. Design phase. The specifications undergo two consecutive design procedures

during the design phase. First comes architectural design, in which the product is
broken down into components, called modules. Then, each module is designed; this
procedure is termed detailed design.

4. Implementation phase. When the developers are satisfied that the product
functions correctly, it is tested by the client (acceptance testing). The implementation
phase ends when the product is accepted by the client and installed on the client’s
computer.

5. Post-delivery maintenance. The product is used to perform the tasks for which it
was developed. During this time, it is maintained. Post-delivery maintenance
includes all changes to the product once the product has been delivered and
installed on the client’s computer and passes its acceptance test.
6. Retirement. Retirement occurs when the product is removed from service. This
occurs when the functionality provided by the product no longer is of any use to the
client organization.
The Object-Oriented paradigm

Software life-cycle models

Software development in theory
 a software product is developed from scratch; _ denotes the empty set. First
the client’s Requirements are determined, and then the Analysis is performed.
 When the analysis artifacts are complete, the Design is produced. This is
followed by the Implementation of the complete software product, which is
then installed on the client’s compute.
Software development is considerably different in practice for two reasons.
 First, software professionals are human and therefore make mistakes.
 Second, the client’s requirements can change while the software is being
developed.
Other life-cycle models
Code-and-Fix Life-cycle Model
 a straightforward approach to product development, especially for prototyping
software-oriented solutions.
The Code and Fix Model is a cyclic process that involves two major steps: Coding
and Fixing.
 Coding: Engineers start writing the program without extensive planning or
well-defined design thinking.
 Fixing: As they encounter software bugs, they address them along the way.

 The product is implemented without requirements or specifications, or any

attempt at design.
Key Features:
 Minimal Planning: Unlike more structured methodologies, this model lacks
extensive product planning.
 Autonomy for Engineers: Cowboy coders (software engineers) work with little
or no guidance from business or design disciplines.
Waterfall Life-cycle Model
 a software development process that consists of several phases that are
performed in a sequential and linear order.
 Each phase must be completed and approved before the next one can begin,
and there is no overlap or iteration between phases.
main features and phases of the waterfall model:
Sequential Approach: The waterfall model follows a strict and structured order of
phases, where the output of one phase becomes the input of the next one.
 The phases are: requirements gathering and analysis, system design,
implementation and unit testing, integration and testing, deployment of
system, and maintenance.
Document-Driven: The waterfall model relies heavily on documentation to ensure
that the project is well-defined and the project team is working towards a common
goal.
Quality Control: The waterfall model places a high emphasis on quality control and
testing at each phase of the project, to ensure that the final product meets the
requirements and expectations of the stakeholders.
Rigorous Planning: The waterfall model involves a rigorous planning process, where
the project scope, timelines, and deliverables are carefully defined and monitored
throughout the project lifecycle.
 The waterfall model requires a clear and accurate estimation of the resources,
costs, and risks involved in the project.
Rapid-Prototyping Life-Cycle Model
 a working model that is functionally equivalent to a subset of the product.
 It is based on the idea of getting feedback from users and stakeholders early
and often and using it to improve the design and functionality of the software.
rapid-prototyping model has the following characteristics:
Iterative and Incremental: The software product is developed in small and
manageable chunks, each of which is a prototype that can be tested and evaluated
by the users and stakeholders.
User-Centered: The users and stakeholders are involved throughout the software
development process, from defining the requirements to testing the prototypes.
Flexible and Adaptable: can accommodate changing requirements and
expectations, as the prototypes can be easily modified and improved based on the
user feedback. The model is also suitable for projects with uncertain or evolving
requirements, where the final product cannot be defined from the start.
Collaborative and Creative: encourages collaboration and communication between
the developers, users, and stakeholders, as they work together to create and test the
prototypes. The model also fosters creativity and innovation, as the developers can
experiment with different ideas and solutions.
Open-source life-cycle model
 a software development process that involves creating, sharing, and
improving software in a collaborative and transparent way.
 The open-source model is based on the principles of freedom, community,
and innovation.
features:
Open Access: The source code of the software is publicly available and can be
accessed, modified, and distributed by anyone who abides by the license terms. The
license terms usually grant users the rights to use, study, change, and share the
software for any purpose.
Open Collaboration: The software is developed by a community of contributors who
work together to improve the software quality, functionality, and usability. The
contributors can be individuals, groups, or organizations who have a common
interest or need for the software.
Open Innovation: The contributors can experiment with new ideas and solutions
and incorporate feedback from users and stakeholders.
phases:
Initiation: They create the initial version of the software and make it available to the
public under an open-source license.
Development: The contributors work on adding new features, fixing bugs, improving
performance, enhancing documentation, etc. The software project follows a release
cycle that determines how often new versions of the software are released to the
public.
Maturity: The software project has a large and active community of contributors and
users, who provide support, feedback, and suggestions. The software project may
also have a governance model that defines the roles and responsibilities of the
contributors and the decision-making process.
Decline: The software project may lose contributors and users, who migrate to other
alternatives
Agile processes
 a set of software development methodologies that emphasize collaboration,
flexibility, and continuous improvement.
 Agile processes aim to deliver value to customers faster and more frequently,
by breaking down large and complex projects into smaller and manageable
iterations.
common agile processes are:
Scrum: a framework that organizes work into fixed-length cycles called sprints,
usually lasting one to four weeks. Scrum also defines roles such as the product
owner, the scrum master, and the development team, as well as events such as the
daily scrum, the sprint review, and the sprint retrospective1.
Kanban: a method that visualizes work as cards on a board, where each card
represents a task or a feature. Kanban also encourages continuous improvement by
measuring metrics such as cycle time, lead time, and throughput2.
Extreme Programming (XP): XP is a practice that focuses on delivering high-quality
software by applying engineering principles and techniques.
The Software processes.
 The software process is the way we produce software.
 It incorporates the methodology with its underlying software life-cycle model)
and techniques, the tools we use and most important of all, the individuals
building the software.
The Unified process
 an iterative and incremental software development process framework. It
provides a structured approach to building software systems.

Iterative and Incremental:

 The UP divides the project into four phases: Inception, Elaboration,
Construction, and Transition.
 Each phase consists of a series of timeboxed iterations.
 During these iterations, development activities progress incrementally,
allowing for continuous refinement and feedback.
The requirements workflow
 Is the process of identifying your project’s exact requirements from start to
finish.
 The aim of the requirements workflow is for the development organization to
determine the client’s needs.

Steps:
  The first task of the development team is to acquire a basic understanding of
the application domain (domain for short), that is, the specific environment in
which the target software product is to operate.
 The domain could be banking, automobile manufacturing, or nuclear physics.
Assign Roles:
 Start by assigning roles within your project.
 Identify both internal and external stakeholders (e.g., customers, department
managers, board members).
 Roles include project managers, administrators, designers, testers, and
developers.
 These stakeholders will help analyse project scope and identify necessary
resources.
The 6-Step Requirements Gathering Process:
Step 1: Assign Roles
 Identify project stakeholders (internal and external).
Stakeholders play a crucial role in analysing project scope.
Step 2: Elicit Requirements & Interview
 Interview all identified stakeholders.
 Understand their needs, expectations, and concerns.
Step 3: Gather and Document
 Write down all requirements.
 Document everything—no detail is too small.
Step 4: List All Assumptions & Requirements
 This is the heart of the process.
 Specify assumptions and compile a comprehensive list of requirements.
Step 5: Monitor Progress
 Continuously track and manage requirements throughout the project lifecycle.
The Analysis workflow
 refers to evaluating the sequence of tasks and activities that produce a
specific workflow outcome.
 The aim of the analysis workflow is to analyse and refine the requirements to
achieve the detailed understanding of the requirements essential for
developing a software product correctly and maintaining it easily.
Workflow Analysis in 6 Steps:
 Process and Workflow Discovery: Collect data on various aspects of the
process, such as task sequences, roles, and dependencies.
  Workflow Visualization: Create a visual representation of the process, such as
flowcharts or swim lane diagrams.
 Measure and Quantify Performance: Evaluate performance metrics (e.g.,
cycle time, throughput) to assess efficiency and identify areas for
improvement.
Common Workflow Analysis Methods:
 Flowcharting: simple visual representations of the sequence of tasks and
decisions within a workflow. They use standardized symbols to represent
different types of tasks, decisions, and flow directions.
 Business Process Mapping: A more detailed form of flowcharting, business
process mapping documents the relationships between different tasks,
subprocesses, resources, and information within a process.
 Value Stream Mapping: This lean management technique analyses and
optimizes workflows by focusing on the flow of value through the process.
 Swimlane Diagrams: These process maps organize tasks and activities into
distinct “lanes” based on the responsible function, department, or role.
Swimlane diagrams clarify responsibilities, identify handoffs or dependencies
between different groups, and uncover potential communication or
coordination issues.
 Process Mining: A data-driven method that uses event logs generated by
various systems (such as ERP, CRM, or BPM platforms) to discover, analyse,
and improve business processes.
 Time and Motion Studies: These involve observing and measuring the time
required to perform tasks within a workflow, identifying inefficiencies, and
suggesting improvements.
 Work Sampling: A statistical technique used to estimate the proportion of
time spent on different tasks or activities within a workflow.
The design workflow
 is the process of laying out all tasks and processes in a visual map, providing
team members and stakeholders with a high-level overview of each task
involved in a particular process.
 The aim of the design workflow is to refine the artifacts of the analysis
workflow until the material is in a form that can be implemented by the
programmers.
Diagram Your Tasks:
 Start by identifying different tasks and activities using a basic flowchart.
 Clearly define start and end points to understand how the process begins and
finalizes.
 Document each task in between, ensuring proper integration into the
workflow.
 Indicate relationships between steps (e.g., dependencies or concurrent
completion).
Consider Inputs and Outputs:
  Think about both the inputs and outputs of your workflow.
 Attach relevant information, including task instructions, required data, source
file links, and checklists.
 Ensure that each task has the necessary resources to complete it
successfully.
Identify Sub-Workflows:
 Break down larger workflows into smaller, more digestible sub-workflows.
 Reuse processes from commonly used workflows if they align with your
project.
 Simplify complex processes for better understanding and execution.
Create Logical Loops:
 Determine how the workflow will progress.
Use two main types of loops:
 “While … do” loop: Perform one task while another occurs concurrently.
 “Repeat … until” loop: Continue a task until another task is approved.
The Implementation Workflow
The aim of the implementation workflow is to implement the target software product
in the chosen implementation language(s).
The Test Workflow
There are two major aspects to testing.
1. Every developer and maintainer is personally responsible for ensuring that his or
her work is correct. Therefore, a software professional must test and retest each
artifact he or she develops or maintains.
2. Once the software professional is convinced that an artifact is correct, it is handed
over to the software quality assurance group for independent testing.

Requirements artifacts
 If the requirements artifacts are to be testable over the life cycle of the
software product, then one property they must have is traceability.
 If the requirements have been presented methodically, properly numbered,
cross-referenced, and indexed, then the developers should have little difficulty
 tracing through the subsequent artifacts and ensuring that they are indeed a
true reflection of the client’s requirements.
Analysis Artifacts
 Both the analysis team and the SQA group must therefore check the analysis
artifacts assiduously.
 They must ensure that the specifications are feasible, for example, that a
specific hardware component is fast enough or that the client’s current online
disk storage capacity is adequate to handle the new product.
Design artifact
 this means that every part of the design can be linked to an analysis artifact.
 A suitably cross-referenced design gives the developers and the SQA group a
powerful tool for checking whether the design agrees with the specifications
and whether every part of the specifications is reflected in some part of the
design.
Implementation artifacts
 Each component should be tested while it is being implemented (desk
checking); and after it has been implemented, it is run against test cases.
 This informal testing is done by the programmer.
 the quality assurance group tests the component methodically; this is termed
unit testing.
Post-delivery maintenance
 Post-delivery maintenance is not an activity grudgingly carried out after the
product has been delivered and installed on the client’s computer.
 Post-delivery maintenance must never be treated as an afterthought. Instead,
the entire software development effort must be carried out in such a way as to
minimize the impact of the inevitable future post-delivery maintenance.
Capability maturity models
 The capability maturity models of the SEI are a related group of strategies for
improving the software process, irrespective of the actual life-cycle model
used.
 The SEI has developed CMMs for software (SW–CMM), for management of
human resources (P–CMM; the P stands for “people”), for systems
engineering (SE–CMM), for integrated product development (IPD–CMM), and
for software acquisition (SA–CMM).
 The strategy of the SW–CMM is to improve the management of the software
process in the belief that improvements in technique are a natural
consequence.
 The resulting improvement in the process as a whole should result in better-
quality software and fewer software projects that suffer from time and cost
overruns.
 Maturity Level 1. Initial Level

 At the initial level, the lowest level, essentially no sound software

engineering management practices are in place in the organization. A
specific project that happens to be staffed by a competent manager
and a good software development team may be successful.

Maturity Level 2. Repeatable Level

 At the repeatable level, basic software project management

practices are in place. Planning and management techniques are based
on experience with similar products; hence, the name repeatable.

 measurements are taken, an essential first step in achieving an

adequate process.

 measurements taken during one project can be used to draw up

realistic duration and cost schedules for future projects.

Maturity Level 3. Defined Level

 At the defined level, the process for software production is fully

documented. Both the managerial and technical aspects of the process
are clearly defined, and continual efforts are made to improve the
process wherever possible.

Maturity Level 4. Managed Level

 A managed-level organization sets quality and productivity goals for

each project. These two quantities are measured continually, and
corrective action is taken when there are unacceptable deviations from
the goal.

Maturity Level 5. Optimizing Level

 The goal of an optimizing-level organization is continuous process

improvement. Statistical quality and process control techniques are
used to guide the organization. The knowledge gained from each
project is utilized in future projects. The process therefore incorporates
a positive feedback loop, resulting in a steady improvement in
productivity and quality.

The Tools of the Trade

Software engineers need two types of tools.

  First are the analytical tools used in software development, such as
stepwise refinement and cost–benefit analysis?

 Then come the software tools, that is, products that assist the teams of
software engineers in developing and maintaining software.

 These usually are termed CASE tools (CASE is an acronym for

Computer-Aided Software Engineering).

Step refinement

 is a problem-solving technique that underlies many software

engineering techniques.

 Stepwise refinement can be defined to postpone decisions on details

until as late as possible to concentrate on the important issues.

 Stepwise refinement underlies many analysis techniques, design, and

implementation techniques, and even testing and integration
techniques.

 Stepwise refinement is of critical importance within the context of the

object-oriented paradigm because the underlying life-cycle model is
iterative and incremental.

Cost-benefit Analysis

 One way of determining whether a possible course of action would be

profitable is to compare estimated future benefits against projected
future costs.

 Cost–benefit analysis is a fundamental technique in deciding whether a

client should computerize his or her business, and if so, in what way.

 The costs and benefits of various alternative strategies are compared.

Divide and conquer

 is probably the oldest analytical tool.

 The idea is to break up a large problem that is hard to solve into

smaller sub problems that hopefully will be easier to solve.

 This approach is used in the Unified Process to handle a large, complex

system.

Separation of concerns

 It is the process of breaking a software product into components

that overlap as little as possible with regard to functionality.
  When separation of concerns is achieved, regression faults are
minimized; if functionality is localized to a single component,
changing that functionality cannot affect any other component.

Scope of CASE