seem4570 system design and implementationseem4570/2017/lecture/lecture09.pdf · schedule. i can’t...

SEEM4570 System Design and Implementation

Lecture 9 – SDLC

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

© 2017 Gabriel Fung 2

Standard

• ISO/IEC 12207:2008 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 43 system and software processes, 95 activities,

325 tasks and 224 outcomes


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(){$db = mysqli_connect("127.0.0.1","abc","123","myDB");$statement = "SELECT name, passwd FROM user";$result = mysqli_query($db, $statement);for(; $row=mysqli_fetch_array($result); ){

// do something}mysqli_close($db);

}


Coupling (3)

• The following program has low degree of coupling • Program 2:

• public function Process(){$db = new DB();$users = $db->getUsers();foreach($users as $user){

// do something}$db->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.• One should move to a phase only when its preceding

phase is completed and perfected.


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

• Some famous models that implemented the concept of iterative model:• Agile Software Development Framework• Extreme Programming • Spiral Model


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• Any comment from these videos?• https://www.youtube.com/watch?v=2ePg0d0RKpw• https://www.youtube.com/watch?v=hxk8W7Z_Q9E


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.


Softwaredevelopersarenotcoders,butexperiencecreators

Agile Development Framework – Principles

• Twelve principles:• Customer satisfaction by rapid delivery of useful software• Welcome changing requirements, even late in development• Deliver output frequently (weeks rather than months)• Working software is the principal measure of progress• Sustainable development, able to maintain a constant pace• Closely collaborate between business people and developers• Face-to-face conversation is the best form of communication• Projects are built around motivated individuals• 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
