seem4570 system design and implementationseem4570/2014/lecture/lecture10.pptx.pdf · seem4570...
TRANSCRIPT
SEEM4570 System Design and Implementation Lecture 10 – Software Development Process
Software Development
A software development process: A structure imposed on the development of a software product
Also known as software development life cycle (SDLC)
Several models proposed. Each describes an approach to a variety of tasks or activities that take place during the process. We will discuss some of these models in this lecture
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Standard
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. There are 23 Processes, 95 Activities, 325 Tasks and 224
Outcomes (the new ISO/IEC 12207:2008 “Systems and software engineering – Software life cycle processes” defines 43 system and software processes).
Copyright (c) 2012. Gabriel Fung. All rights reserved.
ISO/IEC 12207 (1/2)
Why we need standard? A standard can give a common structure and language to all
buyers, suppliers, developers, maintainers, operators, managers and technicians who are involved.
This common language is established in the form of well defined processes.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
ISO/IEC 12207 (2/2)
What is the major characteristic?
The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it.
So, any design principle?
A basic principles: modularity.
Modularity can be divided into coupling and cohesion.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Coupling (1)
Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are.
Two common coupling terms: Loose coupling vs. tight coupling
Related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand.
A good software (design) should have low degree of coupling (loose coupling)!
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Coupling (2)
The following program has high degree of coupling. You need to understand a lot of things (e.g. database structure, connection name) that are not related to the business logic. Program 1:
public function Process(){ $con = mysqli_connect("127.0.0.1","abc","123","myDB"); if (mysqli_connect_errno($con)){ die(mysqli_connect_error()); } $statement = "SELECT name, passwd FROM user"; $result = mysqli_query($con, $statement); for(; $row=mysqli_fetch_array($result); ){ processData($row); } mysqli_close($con); }
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Coupling (3)
The following program has low degree of coupling Program 2:
public function Process(){ $con = new DBConnect(); $userData = getUserData($con); for(; $row=$userData->fetch_array(); ){ processData($row); } $con->close(); }
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Coupling (4)
The goals behind achieving loose coupling between classes and modules are to: Make the code easier to read.
Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes.
Isolate potential changes to a small area of code.
Reuse classes in completely new contexts.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Cohesion (1)
A measure of how closely related all the responsibilities, data, and methods of a class are to each other. i.e., a measure of whether a class has a well-defined role within
the system.
A good software (design) should have high degree of cohesion Think about it:
When you're at a loud party with a lot of different conversations going on at once, it can be difficult to focus on the one conversation you're trying to have. It's much easier to have a conversation in a quiet setting where there's only one conversation going on.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Cohesion (2)
An easy test for cohesion is to look at a class and decide whether all the contents of the class are directly related to and described by the name of the class names. If the class has responsibilities that don't relate to its name,
those responsibilities probably belong to a different class.
If you find a subset of methods and fields that could easily be grouped separately under another class name, then maybe you should extract these methods and fields to a new class.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Overview
The waterfall model is a sequential design process Progress is seen as flowing steadily downwards (like a waterfall)
through different phases, such as requirements, design, implementation, verification, maintenance, …
One should move to a phase only when its preceding phase is completed and perfected.
Copyright (c) 2012. Gabriel Fung. All rights reserved. An Example
Waterfall Model – Why
Time spent early in the software production cycle can lead to greater economy at later stages.
A simple example (idea): A bug found in the early stages (such as requirements
specification or design) is cheaper in money, effort, and time, to fix than the same bug found later (such as coding).
An extreme example If a program design turns out to be impossible to implement, it
is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Related Concept (1)
Big Design Up Front (BDUF) A software development approach in which the program’s
design is to be completed and perfected before that program's implementation is started
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Related Concept (2)
Joel Spolsky, a BDUF lover: Many times, thinking things out in advance saved us serious
development headaches later on. … Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Benefits
Waterfall model emphasis on documentation (such as requirements documents and design documents) as well as source code. If we have less designed and documented methodologies, then
in case some team members leave, knowledge may be lost and may be difficult for a project to recover.
Should a fully working design document be present, new team members or even entirely new teams should be able to familiarize themselves by reading the documents.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Critics (1)
Poorly adaptable to changing requirements
Assumes designers are able to foresee problem areas without extensive prototyping or implementation
Ignore there is an overhead to be balanced between the time spent planning and the time that fixing a defect would actually cost If the cost of planning is greater than the cost of fixing then
time spent planning is wasted.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Critics (2)
It is quite impossible for many non-trivial project to finish a phase perfectly before moving to the next phase Clients may not know exactly what requirements they need
before reviewing a working prototype and commenting on it. They may change their requirements constantly.
Designers and programmers may have little control over this.
If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. Investing a lot on planning (e.g. BDUF) is not wise
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Waterfall Model – Critics (3)
Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a
particular area of program functionality is extraordinarily difficult to implement.
In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Overview (1)
Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with
the cyclic interactions in between.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Overview (2)
Develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier versions of the system.
Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented.
At each iteration, design modifications are made and new functional capabilities are added.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Related Concept
Two kinds of famous models that implemented the concept of iterative model: Spiral Model
Extreme Programming
Agile Software Development Framework
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Why
Working software vs. comprehensive documentation Working software will be more useful and welcome than just
presenting documents to clients in meetings
Customer collaboration vs. contract negotiation Requirements cannot be fully collected at the beginning,
therefore continuous customer or stakeholder involvement is very important
Responding to change vs. following a plan Focus on quick responses to change and continuous
development
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Benefits
Suitable for certain types of environment, including small teams of experts.
The customer and developers are in close communication. In water-fall model, customers are initially represented by the
requirement and design documents.
Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the process, nor all at the end. Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Iterative Model – Critics
Unstable requirements
Lack of overall design specification or documentation. No documented compromises of user conflicts
Inefficient in large organizations or involve a project involve many parties
It is developer-centric rather than user-centric. Focuses on processes for getting requirements and developing
codes and does not focus on product design
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Agile Development Framework
Proposed by Agile Alliance in 2001.
Uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Uses feedback, rather than planning, as their primary control
mechanism.
The feedback is driven by regular tests and releases of the evolving software.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Software developers are not coders, but experience creators
Agile Development Framework – Principles
Twelve principles: Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Close, daily co-operation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances
Agile Development Framework – Concept
Agile methods break tasks into small increments (known as iteration) with minimal planning and do not directly involve long-term planning.
Each iteration involves: Working through a full software development cycle, including
planning, requirements analysis, design, coding, unit testing, … Demonstrate to stakeholders.
Iterations are short time frames Typically last from one to four weeks. This minimizes overall risk and allows the project to adapt to changes
quickly.
An iteration might not add enough functionality to warrant a market release, but will have an available release (with minimal bugs)
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Agile Development Framework – Characteristics
Team size is typically small (5-9 people) to simplify team communication and team collaboration.
Emphasize face-to-face communication over written document
Larger development efforts can be delivered by multiple teams working toward a common goal or on different parts of an effort. This might require a coordination of priorities across teams
No matter what development disciplines are required, each agile team will contain a customer representative
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Extreme Programming
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
It advocates frequent “releases” in very short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Spiral Model (1)
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Spiral Model (2)
Combines the features of iterative model and waterfall model Allows for incremental releases of the product, or incremental
refinement through each time around the spiral.
Starting at the center, each turn around the spiral goes through several task regions: Determine the objectives, alternatives, and constraints on the
new iteration.
Evaluate alternatives and identify and resolve risk issues.
Develop and verify the product for this iteration.
Plan the next iteration.
Copyright (c) 2012. Gabriel Fung. All rights reserved.
Spiral Model (3)
The spiral model is intended for large (e.g. few years), expensive (e.g. up to a few millions) and complicated projects (e.g. military project). Future Combat System (FCS) (2003 – 2009)
Research/create unattended ground sensors (UGS); unmanned aerial vehicles (UAVs); unmanned ground vehicles; and eight manned ground vehicles.
In 2009 Pentagon and army officials announced that the FCS effort would be swept into a new, pan-army program called the Army Brigade Combat Team Modernization Program.
2 Years an iteration
Copyright (c) 2012. Gabriel Fung. All rights reserved.