SEEM4570 System Design and Implementationseem4570/2014/Lecture/lecture10.pptx.pdf · SEEM4570...

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).


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.


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.


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)!


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); }


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(); }


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.


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.


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.


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.


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


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.


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.


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.



  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



  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.


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.


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.


Iterative Model – Related Concept

  Two kinds of famous models that implemented the concept of iterative model:   Spiral Model

  Extreme Programming

  Agile Software Development Framework


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


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


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


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.


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)


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


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.


Spiral Model (1)


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.


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


SEEM4570 System Design and Implementationseem4570/2014/Lecture/lecture10.pptx.pdf · SEEM4570...

Documents

Transcript of SEEM4570 System Design and Implementationseem4570/2014/Lecture/lecture10.pptx.pdf · SEEM4570...