Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx

CPE 809
ADVANCED SOFTWARE
ENGINEERING
DR. DADA E. GBENGA

Introduction to Software Development
•Software development became a very important topic
because of what was then called the ‘software crisis’.
•This software crisis resulted directly from the
introduction of the third-generation computer hardware.
•Compared with software systems developed for the
second-generation computers.

•Software systems nowadays often have among the
others the following features:
•they model parts of the real world;
•they are large and complex;
•they are abstract;
•they must be highly dependable;
•they need to be better maintainable: as the real world
changes, so too must the software to meet the
changing requirements;

•they must be user friendly, and thus the user interface in
a software system is an important part. Software
development was in crisis because the methods (if there
were any) used were not good enough:
•techniques applicable to small systems could not be
scaled up;
•major projects were sometimes years late, they cost
much more than originally predicted;
•software developed were unreliable, performed poorly,
and were difficult to maintain.

•The fact that hardware costs were tumbling while
software costs were rising rapidly called for new
theories, techniques, methods and tools to control the
development process of software systems.
•Therefore, software development is concerned with the
theories, methods and tools which are needed to
develop software.
•Its aim is the production of dependable software,
delivered on time and within budget, that meets the
user’s requirement.

Software products
•The objective of software development is to produce
software products with high-quality.
•Software products are software systems delivered to a
customer with the documentation which describes how
to install and use the system.
•The quality of a software product is judged by, apart
from the services provided by the product, the
characteristics displayed by the product once it is
installed and put into use.

Characteristics of Software Products
• Usability: It must be useful and usable to make people’s lives
easier and better.
• Maintainability: It should be possible to evolve software to meet
the changing needs of customers.
• Dependability: Software dependability includes a range of
characteristics, such as reliability, security and safety. It should not
cause physical or economic damage in the event of system failure.
• Efficiency: Software should not make wasteful use of system
resources such as memory and processor cycles.
• Robustness: Software should fail only under extreme conditions
• Portability: Should be possible to move from one environment to
another

•It should be noted that the relative importance of these
characteristics obviously varies from system to system
•And that optimizing all these characteristics is difficult
as some are exclusive.
•Also the relationship between the cost and
improvements in each characteristic is not a linear one.

•To build good systems, we need
•a well-defined development process with clear
phases of activities, each of which has an end-
product,
•methods or techniques for conducting the phases of
activities and for modelling their products,
•tools for generating the products.

Software Development Stages
•Building a software product is a process consisting of
several distinct stages.
•Each stage has its own deliverables and is bound by a
specific time frame.
•Depending on the project, certain stages gain
additional weight in the overall effort to implement the
software product.

1. Research Stage
•The project owner, the project manager and the project
team gather and exchange information.
•The project owner is responsible for formulating
requirements and passing them on to the project
manager.
•The project owner has to first define a set of goals.
Then he has to envision the way a software product
will help him achieve those goals.

Research Stage Cont’d
•The project manager is responsible for receiving the
requirements from the project owner, evaluating them
and passing them to the project team as technical
specification. He do research on market characteristics
and user behaviour patterns.
•The project team is responsible for evaluating the
requirements from a technical perspective. The project
team will have to research the frameworks, API’s,
libraries, versioning tools and hosting infrastructure
that will be required in order to build the software
product.

2. Planning Stage
• All the elements are set in order to develop the software
product.
• Planning starts with defining the overall flow of the
application and then breakdown the flow into smaller, easier
to manage subassemblies.
• Based on the required functionality a database structure is
designed. Taking into account the overall flow of the
application, the subassemblies, functionalities and database
structure.
• The project manager together with the project team have to
choose the technology that will be employed to develop the
application.

3. Design Stage
•The layout of the application is created.
•Web applications and mobile applications tend to grant
more impotence to layout than desktop applications.
•Depending on the nature of the application designs can
range from rough and functionality driven to complex
and artistic.
•Project owner comes up with new requirements that have
to be summited to research and planning.

4. Development Stage
• Code is written and the software application is actually
built.
• The development stage starts with setting up the
development environment and the testing environment.
• The development environment and the test environment
should be synchronized using always the same protocol.
• Code is written on the development environment and
uploaded on the test environment using the
synchronization protocol.
• The project manager has to determine actual progress and
evaluate it against the initial planning.

5. Testing Stage
• Programming and design errors are identified and fixed.
• Programming errors are scenarios were the application
crashes or behave in a way it was not supposed to
according to the designed architecture.
• Programing errors also consist in security or usability
issues.
• If the application is vulnerable to attacks and can
therefore allow attackers access to private data, then that
is regarded as a programming error.
• Design errors occur in the planning stage, have a
significant impact on the project and are usually harder to
fix.

6. Setup Stage
• This is the stage where the application is installed on the
live environment.
• The setup stage precedes the actual exploitation of the
software product.
• The setup entails configuring the live environment in
terms of security, hardware and software resources.
• Back-up procedures are defined and tested.
• The actual setup of the software product includes copying
the source code, importing the database, installing third
party applications if required, installing cron-jobs if
required and configuring API’s if required.

7. Maintenance Stage
• Covers software development subsequent to the application
setup and ensuring that the application is running within the
planned parameters.
• Ensuring that the application is running properly is done by
monitoring the firewall, mail, HTTP, FTP, MySQL and SSH
error logs.
• Also monitoring traffic data will provide valuable input on
potential issues that may affect the application’s performance.
• Systematically testing functionalities for errors that were not
identified in the testing stage or for issues that are not displayed
in the error logs.
• Provides the opportunity to add new features of functionality to
the software application.

Software development methodologies
•A software development methodology is a set of rules
and guidelines that are used in the process of
researching, planning, designing, developing, testing,
setup and maintaining a software product.
•The methodology also includes core values that are
upheld by the project team and tools used in the
planning, development and implementation process.

Software Development Life Cycle
•The software life cycle is the sequence of different
activities that take place during software development.
There are also different deliverables produced.
•Although deliverables can be agreements or evaluations,
normally deliverables are objects, such as source code or
user manuals. Usually, the activities and deliverables are
closely related.

•Milestones are events that can be used for telling the
status of the project. For example, the event of completing
the user manual could be a milestone.
•For management purposes, milestones are essential
because completion of milestones allow, the manager to
assess the progress of the software development.
Software Development Life Cycle

TYPES OF SOFTWARE LIFE CYCLE
ACTIVITIES
1.1.1.1 Feasibility — Determining if the proposed development is
worthwhile.
Market analysis — Determining if there is a potential market for this
product.
1.1.1.2 Requirements — Determining what functionality the
software should contain.
Requirement elicitation — Obtaining the requirements from the user.
Domain analysis — Determining what tasks and structures are
common to this problem.

ACTIVITIES
•1.1.1.3 Project planning — Determining how to develop
the software.
Cost analysis — Determining cost estimates.
Scheduling — Building a schedule for the development.
Software quality assurance — Determining activities that
will help ensure quality of the product.
Work-breakdown structure — Determining the subtasks
necessary to develop the product.

ACTIVITIES
1.1.1.4 Design — Determining how the software should
provide the functionality.
Architectural design — Designing the structure of the
system.
Interface design — Specifying the interfaces between the
parts of the system.
Detailed design — Designing the algorithms for the
individual parts.
1.1.1.5 Implementation — Building the software.

ACTIVITIES
1.1.1.6 Testing — Executing the software with data to help ensure
that the software works correctly.
Unit testing—Testing by the original developer.
Integration testing—Testing during the integration of the software.
System testing—Testing the software in an environment that
matches the operational environment.
Alpha testing—Testing by the customer at the developer’s site.
Beta testing—Testing by the customer at the customer’s site.
Acceptance testing—Testing to satisfy the purchaser.
Regression testing—Saving tests from the previous version to
ensure that the new version retains the previous capabilities.

ACTIVITIES
1.1.1.7 Delivery — Providing the customer with an effective
software solution.
Installation — Making the software available at the
customer’s operational site.
Training — Teaching the users to use the software.
Help desk — Answering questions of the user.
1.1.1.8 Maintenance — Updating and improving the
software to ensure continued usefulness.

TYPICAL DOCUMENTS
1.1.2.1 Statement of work—Preliminary description of desired
capabilities, often produced by the user.
1.1.2.2 Software requirements specification—Describes what the
finished software will do.
Object model — Shows main objects/classes.
Use case scenarios — Show sequences of possible behaviors from the
user’s viewpoint.
1.1.2.3 Project schedule — Describes the order of tasks and estimates
of time and effort necessary.
1.1.2.4 Software test plan — Describes how the software will be tested
to ensure proper behavior.
Acceptance tests — Tests designated by the customer to determine
acceptability of the system.

1.1.2.5 Software design — Describes the structure of the
software.
Architectural design — The high-level structure with the
interconnections.
Detailed design — The design of low-level modules or objects.
1.1.2.6 Software quality assurance plan (SQA plan) —
Describes the activities that will be done to ensure quality.
1.1.2.7 User manual — Describes how to use the finished
software.
TYPICAL DOCUMENTS

TYPICAL DOCUMENTS
1.1.2.8 Source code — The actual product code.
1.1.2.9 Test report — Describes what tests were done and
how the system behaved.
1.1.2.10 Defect report — Describes dissatisfaction of the
customer with specific behavior of the system; usually, these
are software failures or errors.

Documents in the software life cycle:
• Final user manual Implementation phase
• Architectural design Design phase
• SQA plan Project planning phase
• Module specification Design phase
• Source code Implementation phase
• Statement of work Feasibility phase
• Test plan Requirements phase
• Preliminary user manual Requirements phase
• Detailed design Design phase
• Cost estimate Project planning phase
• Project plan Project planning phase

Software Life Cycle Models
1. Waterfall Model/ The Linear Sequential Model
Is the first methodology generally acknowledged as being
dedicated to software development.
• The Waterfall methodology is linear sequential process
where every stage starts only after the previous has been
completed.
• Each stage has its own deliverables.
• The Waterfall methodology is predictable and values
rigorous software planning and architecture.
• The project owner’s feedback is received after the software
application is completely developed and tested.

1. Characteristics of Waterfall Model
• comprehensive documentation
• meticulous planning
• linear-sequential process
• each phase has its own deliverables

Advantages & Disadvantages of Waterfall Model
Advantages
• easy to manage
• easy to understand for the project owner and team
Disadvantages
• working code is delivered late in the project
• does not cope well with changing requirements
• low tolerance for design and planning

2. Prototyping Model
•It evolved out of the need to better define
specifications and it entails building a demo version
of the software product that includes the critical
functionality.
•Initial specifications are defined only to provide
sufficient information to build a prototype.
•The prototype is used to refine specifications as it
acts as baseline for communication between project
team and project owner.

•The prototype is not meant to be further developed
into the actual software product.
•Prototypes should be built fast and most of the times
they disregard programming best practices.
•The project owner’s feedback is received after the
prototype is completed.

•The Prototyping methodology is suitable for large
scale projects where is almost impossible to properly
define exhaustive requirements before any actual
codding is performed.
•Prototyping methodology is also suitable for unique
or innovative projects where no previous examples
exist.

Fig. 2. Prototyping methodology

Characteristics of Prototyping methodology
•build one or more demo versions of the software
product
•project owner is actively involved
•prototypes are meant to be discarded

Advantages
•accurate identification of application requirements
•early feedback from the project owner
•improved user experience
•early identification of missing or redundant functionality
•writing code is valued over writing specifications
Disadvantages
•leads to unnecessary increase of the application’s complexity
•increased programming effort
•costs generated by building the prototype functionality is high

3. Iterative and incremental Model
•It relies on building the software application one step
at the time in the form of an expanding model.
•Based on initial specification a basic model of the
application is built. Unlike the prototype, the model is
not going to be discarded, but is instead meant to be
extended.
•After the model is tested and feedback is received
from the project owner specifications are adjusted and
the model is extended.

•The process is repeated until the model becomes a
fully functional application that meets all the project
owner’s requirements.
•The project owner’s feedback is received after each
iteration is completed.
•The Iterative and incremental methodology
emphasizes design over documentation and is
suitable for medium and large projects.

Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx

Characteristics of Iterative and incremental Model
•build an initial model that is meant to be extended in successive iterations
• emphasizes design over documentation
• project owner is actively involved
Advantages
•continuous feedback from the project owner
•multiple revisions on the entire application and on specific functionality
•working code is delivered early in the project
Disadvantages
• each iteration is a rigid structure that resembles a small scale waterfall project

4. Spiral Model
•It focuses on identifying objectives and analysing viable
alternatives in the context of well documented project
constrains.
•It has 4 major phase: planning, risk analysis, development
and evaluation.
•Project will follow each phase multiple times in the above
mentioned order until the software application is ready to be
setup on the live environment.
•It emphasizes risk analysis and always evaluates multiple
alternatives before proceeding to implementing one.

•The project owner’s feedback is received after the first
iteration of the spiral is completed.
•The Spiral methodology is suitable for medium and
large scale projects.
•It has also proven more effective in implementing
internal projects as identifying risks proprietary to your
own organization is easier.

Characteristics of Spiral Model
•focuses on objectives, alternatives and constrains
•has 4 major phase: planning, risk analysis, development
and evaluation
•emphasises risk analysis
•evaluates multiple alternatives before proceeding to the
planning stage

Advantages
•working code is delivered early in the project
•minimizes risk
•strong documentation
Disadvantages
•costs generated by risk handling
•dependent on accurate risk analysis

5. Rapid application development Model
•This is a development lifecycle designed to give much
faster development and higher quality results than those
achieved with the traditional methodologies.
•It is designed to take the maximum advantage of
powerful development software.
•Rapid application development imposes less emphasis
on planning tasks and more emphasis on development.
•Development cycles are time boxed and multiple cycles
can be developed at the same time.

Fig. 5. Rapid application development methodology

Characteristics of Rapid application development Model
•less emphasis on planning tasks and more focus on development
•timebox approach
Advantages
•applications are developed fast
•code can be easily reused
Disadvantages
•poor documentation
•high development costs
•code integration issues
•application has to be broken into modules

6. Extreme programming Model
•Extreme programming breaks the conventional
software development process into smaller more
manageable chunks.
•Rather than planning, analysing, and designing for the
entire project at once, extreme programming exploits
the reduction in the cost of changing software to do all
of these activities a little at a time, throughout the
entire software development process.
•It enforces pair programming where two developers
use the same computer.

•One is writing code and the other is supervising.
•They change roles at regular intervals.
•For reducing the number of errors it relies heavily on
unit testing and developers are required to write tests
before writing the actual code.
•There is a collective ownership code policy where any
developer can change any code sequence even if it was
not written by him.
•The project owner is the one that decides the priority of
the tasks.

Fig. 6. Extreme programming methodology

•Extreme programming methodology requires that a
representative of the project owner is always with the
development team in order to have access to continuous
and relevant feedback.
•The Extreme programming methodology is suitable for
small, medium and large scale projects.

Characteristics of Extreme programming Model
• pair programming
•unit testing
•fast consecutive releases
•collective ownership
•on-site project owner
•open workspace
•project owner decides the priority of tasks

Advantages
•application gets very fast in the production environment
•frequent releases of working code
•reduced number of bugs
•smooth code integration
•continuous feedback from the project owner
Disadvantages
•lack of documentation
•developers reluctance to pair programing
•developers reluctance to write tests first and code later
•requires frequent meetings
•lack of commitment to a well-defined product leads to project owner
reluctance

OPEN SOURCE SOFTWARE DEVELOPMENT MODEL
• Open source software development process sometimes also referred as free and open
source software development (FOSSD) is a decentralized methodology with no central
authority, project owner, no compensation for the project team, no accountability and yet
with a high success rate
• Open Source software during the last ten years has gained wide spread popularity.
Software like GNU Linux, MYSQL, Apache web server, Mozilla web browser, Open
office, Perl programming language etc. getting the phenomenal success among the
software users.
• Open source software development defies traditional economic theory as thousands of
programmers work on writing, debugging and testing software without expecting any
direct compensation. Most open source software developers will never meet face to
face and yet

WHAT IS OPEN SOURCE SOFTWARE?
• Open-source software (OSS) it is a computer software with its source code made
available with a license in which the copyright holder provides the rights to
study, change, and distribute the software to anyone and for any purpose.
• Open source software is computer software that is available in source code form
that permits users to study the software, to use software freely, change and
improves software as per his requirements.
• Generally open source refers to a program in which the source code is available
to the general public for use and/or modification from its original design free of
charge.

KEY CONDITIONS TO DEFINE OSS:
1. The source code must be available to user.
2. The software must be redistributable.
3. The software must be modifiable and the creation of derivative
works must be permitted.
4. The license must not discriminate against any user, group of users,
or field of endeavor.
5. The license must apply to all parties to whom the software is
distributed.
6. The license cannot restrict aggregations software.

OPEN-SOURCE SOFTWARE DEVELOPMENT MODEL

Advantages and Disadvantages OSS
Advantages
• low costs
• highly motivated and
• dedicated developers
• comprehensive testing as
• code is reviewed by a large
• number of developers
Disadvantages
- low accountability for submitted code
- no central management authority
- unstructured approach to development

Microsoft Solutions Framework (MSF)
• The Microsoft Solutions Framework (MSF) is an adaptable approach for
successfully delivering technology solutions faster, with fewer people and
less risk, while enabling higher quality results. MSF helps teams directly
address the most common causes of technology project failure —
improving success rates, solution quality, and business impact.
• Microsoft. MSF is not limited to developing applications only, it is also
applicable to other IT projects like deployment, networking or
infrastructure projects. MSF does not force the developer to use a specific
methodology (Waterfall, Agile) but lets them decide what methodology to
use.

MSF focuses on:
• Aligning business and technology goals
• Establishing clear project goals, roles, and responsibilities
• Implementing an iterative, milestone/checkpoint-driven process
• Managing risk proactively
• Responding to change effectively

Key elements of MSF
• The MSF Foundational Principles and Mindsets to orient and guide
teams and team members how to work together to deliver a solution.
• The MSF Team Model enables projects to scale, ensures teams meet a
variety of stakeholder needs, and defines goal-driven roles and
responsibilities.
• The MSF Governance Model (formally called the MSF Process Model)
drives fast, high-quality results through a proven project life cycle that
identifies key project activities

Foundational Principles
• Foster open communication
• Work towards a shared vision
• Empower team members
• Establish clear accountability and shared responsibility
• Focus on delivering business value
• Stay agile, expect change
• Invest in quality
• Learn from all experiences
• Partner with customers

MSF Team Model
• The members of this team would be:
• Product Management: Mainly deals with customers and define project
requirements, also ensures customer expectations are met
• Program Management: Maintains project development and delivery to the
customer
• Architecture: Responsible for solution design, making sure the solution design
optimally satisfies all needs and expectations
• Development: Develops according to the specifications
• Test: Tests and assures product quality
• Release/Operations: Ensures smooth deployment and operations of the software

MSF Governance Model
• The MSF Governance Model has five overlapping tracks of activity,
each with a defined quality goal. These tracks of activity define what
needs to be accomplished and leave how they are accomplished to
the team selected methodology. For instance, these tracks can be
small in scope and performed quickly to be consistent with an Agile
methodology, or can be serialized and elongated to be consistent with
a Waterfall methodology.

Tracks of activity MSF:
• Envision - think about what needs to be accomplished and identify
constraints
• Plan - plan and design a solution to meet the needs and expectations
within those constraints
• Build - build the solution
• Stabilize - validate that the solution meets the needs and
expectations... "synch and stabilize"
• Deploy - deploy the solution

Advantages and Disadvantages of MSF
Advantages
• supports multiple process approaches
• solid risk handling
• Policies built to respond effectively to change reduces team size
Disadvantages
• difficult to setup and configure

The Software Process Model
A software process model (SPM) describes the processes that are
done to achieve software development. A software process model
usually includes the following:
• Tasks
• Artifacts (files, data, etc.)
• Actors
• Decisions (optional)
The standard software process model uses ovals for tasks and processes.
The artifacts are represented by rectangles and the actors by stick figures.
Many software process models do not include decisions. We will use diamonds
whenever we show decisions. The flow is shown by arcs and is usually left-to-
right and top-down. Arcs are normally not labeled.

Example
Process diagram for unit testing with Decision.

Rules and Interpretations for Correct Process Models:
• Two tasks cannot be connected by an arc. Tasks must be separated
by artifacts.
• A task is not executable until its input artifacts exist.
• There are one or more start tasks and one or more terminal tasks.
• All tasks must be reachable from the start task.
• There is a path from every task to the terminal task.
Software process models can be descriptive; that is, they can describe what has
happened in a development project. The descriptive model is often created as
part of a postmortem analysis of a project.
It can also be prescriptive; that is, the software process model can describe
what is supposed to happen. Prescriptive software process models can be used
to describe the standard software development process.

Differences between a software life cycle
model and a process model
• A software life cycle (SLC) model shows the major phases and the
major deliverables,
• while a process model depicts the low-level tasks, the artifacts needed
and produced, and the actors responsible for each low-level task.

Software Project Management
• Software project management is the important task of planning, directing,
motivating, and coordinating a group of professionals to accomplish
software development.
• Software project management uses many concepts from management in
general, but it also has some concerns unique to software development.
One such concern is project visibility.
• The lack of visibility of the software product during software development
makes it hard to manage.

Management Approaches
• In process-oriented management, the management of the small tasks
in the software life cycle is emphasized. In project management, the
team achieving the project is emphasized. This results in important
differences in viewpoint.
• In a process management approach, if the team does not follow the
prescribed software life cycle, this would be a major difficulty.
• In a project management approach, success or failure is directly
attributed to the team.

Critical Practices from Software Project Managers
• Adopt continuous risk management.
• Estimate cost and schedule empirically.
• Use metrics to manage.
• Track earned value.
• Track defects against quality targets.
• Treat people as the most important resource.
• Adopt life cycle configuration management.
• Manage and trace requirements.
• Use system-based software design.
• Ensure data and database interoperability.
• Define and control interfaces.
• Design twice, code once.
• Assess reuse risks and costs.
• Inspect requirements and design.
• Manage testing as a continuous process.
• Compile and smoke-test frequently.

Capability Maturity Model
The Software Engineering Capability Maturity Model (SE-CMM) is used to rate an
organization’s software development process. An assessment of an organization’s
practices, processes, and organization is used to classify an organization at one of
the following levels:
• Level 1: Initial—This is the lowest level and usually characterized as chaotic.
• Level 2: Repeatable—This level of development capability includes project
tracking of costs, schedule, and functionality. The capability exists to repeat
earlier successes.
• Level 3: Defined—This level has a defined software process that is documented
and standardized. All development is accomplished using the standard processes.
• Level 4: Managed—This level quantitatively manages both the process and the
products.
• Level 5: Optimizing—This level uses the quantitative information to continuously
improve and manage the software process.

Object Oriented Analysis and Design.
Object-oriented analysis and design (OOAD) is a popular technical approach for
analyzing, designing an application, system, or business by applying the object-
oriented paradigm and visual modeling throughout the development life cycles to
foster better stakeholder communication and product quality.
The software design improves when we use object-oriented concepts because
1. Object-orientation works at higher level of abstraction. The development can
proceed at the object level and ignore the rest of the system for as long as
necessary.
2. The data on which a system is based tends to be more stable than the
functionality it supports.
3. Object-orientated programming encourages and supports good programming
techniques.
4. Object-oriented programming design and programming promote code re-use.

Unified Modeling Language (UML)
• It's an international industry standard graphical notation used for
describing, visualizing, constructing and documenting the artifacts of a
software system.
Notation
• Object classes are rectangles with the name at the top, attributes in the
middle section and operations in the bottom section
• Relationships between object classes (known as associations) are
shown as lines linking objects
• Inheritance is referred to as generalisation and is shown ‘upwards’
rather than ‘downwards’ in a hierarchy.

Different ways of viewing the UML
• Structural models describe the elements of the system (classes,
objects, etc.) and their relationships (association, uses, etc.). Examples
are Class diagram, Object diagram.
• Behavioural models describe the behaviour of the system over time
describing interactions, workflow, and state changes between
elements. Examples are Use case diagram, Sequence diagram

CASE tools
CASE tools are software systems which are designed to support routine
activities in the software process such as editing design diagrams,
checking diagram consistency and keeping track of program tests which
have been run.
CASE can be classified as follows:
1. Functional perspective: Tools are classified according to their specific
function
2. Process perspective: Tools are classified according to process activities
that are supported
3. Integration perspective: Tools are classified according to their
organization into integrated units.

Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx

More Related Content

Similar to Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx (20)

More from Muhammad54342 (14)

Recently uploaded (20)

Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx