Before the project
Download
1 / 79

Before The Project - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

Before The Project. Chapter 7 Pragmatic Programmer. The Requirements Pit. Tip 51: Don’t Gather Requirements – Dig for Them Tip 52: Work with a User to Think Like a User Tip 53: Abstractions Live Longer than Details Tip 54: Use a Project Glossary. Overspecifying.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Before The Project' - derex


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Before the project l.jpg

Before The Project

Chapter 7

Pragmatic Programmer

SE Fall 2002


The requirements pit l.jpg
The Requirements Pit

  • Tip 51: Don’t Gather Requirements – Dig for Them

  • Tip 52: Work with a User to Think Like a User

  • Tip 53: Abstractions Live Longer than Details

  • Tip 54: Use a Project Glossary

SE Fall 2002


Overspecifying l.jpg
Overspecifying

  • Don’t be too specific. Good requirement documents remain abstract.

  • Requirements

    • Are NOT architecture

    • Are NOT design, NOR user interface

    • Are need

SE Fall 2002


The specification trap l.jpg
The Specification Trap

  • Tip 57: Some Things Are Better Done than Described

  • Seamless approach:specification and implementation are different aspects of the same process: each should flow directly into the next, with no artificial boundaries.

SE Fall 2002


Requirements engineering l.jpg

Requirements Engineering

Bernd Bruegge

SE Fall 2002


Slide6 l.jpg

  • System Identification

  • Development of a system is not just done by taking a snapshot of a scene (domain)

  • Definition of the system boundary

    • What is inside, what is outside?

  • How can we identify the purpose of a system?

  • Requirements Process

    • Requirements Engineering: Definition of the system in terms understood by the customer

    • Requirements Analysis: Technical specification of the system in terms understood by the developer.

SE Fall 2002


Slide7 l.jpg

  • Requirements Engineering

  • Very challenging activity

  • Requires collaboration of people with different backgrounds

    • User with application domain knowledge

    • Developer with implementation domain knowledge

  • Bridging the gap between user and developer:

    • Scenarios: Example of the use of the system in terms of a series of interactions between the user and the system

    • Use cases: Abstraction that describes a class of scenarios

SE Fall 2002


Slide8 l.jpg

  • Requirements Validation

  • Critical step in the development process,

    • Usually after requirements engineering or requirements analysis. Also at delivery.

  • Requirements validation criteria:

    • Correctness:

      • The requirements represent the client’s view.

    • Completeness:

      • All possible scenarios through the system are described, including exceptional behavior by the user or the system

    • Consistency:

      • There are functional or nonfunctional requirements that contradict each other

    • Realism:

      • Requirements can be implemented and delivered

SE Fall 2002


Slide9 l.jpg

  • With AOSD we can improve traceability of requirements.

  • Goal: can we map requirements to aspects?

SE Fall 2002


Slide10 l.jpg

  • Types of Requirements Engineering

  • Greenfield Engineering

    • Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client

    • Triggered by user needs

  • Re-engineering

    • Re-design and/or re-implementation of an existing system using newer technology

    • Triggered by technology enabler

  • Interface Engineering

    • Provide the services of an existing system in a new environment

    • Triggered by technology enabler or new market needs

Example: Eclipse as new technology enabler

SE Fall 2002


Slide11 l.jpg

  • Actors

  • Actors constitute everything that is external to the system and that communicates and interacts with the system.

    • human users, external hardware and other systems

  • Actors communicate by sending and receiving stimuli to and from the system. Each actor has a name.

  • Graphical Notation: A stick figure with the name of the actor.

SE Fall 2002


Slide12 l.jpg

  • Scenarios

  • “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]

  • A concrete, focused, informal description of a single feature of the system used by a single actor.

  • Scenarios can have many different uses during the software lifecycle

SE Fall 2002


Slide13 l.jpg

  • Types of Scenarios

  • As-is scenario:

    • Used in describing a current situation. Usually used during re-engineering. The user describes the system.

  • Visionary scenario:

    • Used to describe a future system. Usually described in greenfield engineering or reengineering.

    • Can often not be done by the user or developer alone.

  • Evaluation scenario:

    • User tasks against which the system is to be evaluated

  • Training scenario:

    • Step by step instructions designed to guide a novice user through a system

SE Fall 2002


Slide14 l.jpg

  • Heuristics: How do I find Scenarios?

  • Ask yourself or the client the following questions:

    • What are the primary tasks that the system needs to perform?

    • What data will the actor create, store, change, remove or add in the system?

    • What external changes does the system need to know about?

    • What changes or events will the actor of the system need to be informed about?

  • To answer these questions, develop scenarios!

SE Fall 2002


Slide15 l.jpg

  • Example: Accident Management System

  • What needs to be done to report a “Cat in a Tree” incident?

  • What do you need to do if a person reports “Warehouse on Fire?”

  • Who is involved in reporting an incident?

  • What does the system do if no police cars are available? If the police car has an accident on the way to the “cat in a tree” incident?

  • What do you need to do if the “Cat in the Tree” turns into a “Grandma has fallen from the Ladder”?

  • Can the system cope with a simultaneous incident report “Warehouse on Fire?”

SE Fall 2002


Slide16 l.jpg

  • Scenario Example: Warehouse on Fire

  • Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, activates the “Report Emergency” function from her FRIEND laptop.

  • Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, he requests several paramedic units on the scene given that area appear to be relatively busy. He confirms his input and waits for an acknowledgment.

  • John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He creates allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.

  • Alice received the acknowledgment and the ETA.

SE Fall 2002


Slide17 l.jpg

  • Observations about Warehouse on Fire Scenario

  • Concrete scenario

  • Describes a single instance of reporting a fire incident.

  • Does not describe all possible situations in which a fire can be reported.

  • Participating actors

  • Bob, Alice and John

  • Next goal, after the scenarios are formulated:

  • Find the use case that specifies all possible instances of how to report a fire

  • What roles are the played by the participating actors?

SE Fall 2002


Slide18 l.jpg

  • Use Case Example: ReportEmergency

  • The FieldOfficer activates the “Report Emergency” function of her terminal. FRIEND responds by presenting a form to the officer.

  • The FieldOfficer fills the form, by selecting the emergency level, type, location, and brief description of the situation. The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, at which point, the Dispatcher is notified.

  • The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher selects a response and acknowledges the emergency report.

  • The FieldOfficer receives the acknowledgment and the selected response.

SE Fall 2002


Slide19 l.jpg

  • Use Case Example: ReportEmergency ctd

  • Use case name: ReportEmergency

  • Participating Actors:

  • Field Officer (Bob and Alice in the Scenario)

  • Dispatcher (John in the Scenario)

  • Exceptions:

  • The FieldOfficer is notified immediately if the connection between her terminal and the central is lost.

  • The Dispatcher is notified immediately if the connection between any logged in FieldOfficer and the central is lost.

  • Nonfunctional Requirements:

  • The FieldOfficer’s report is acknowledged within 30 seconds. The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

SE Fall 2002


Slide20 l.jpg

  • Use Cases

  • A use case is a flow of events in the system, including interaction with actors

  • It is initiated by an actor

  • Each use case has a name

  • Each use case has a termination condition

  • Graphical Notation: An oval with the name of the use case

  • Use Case Model: The set of all use cases specifying the complete functionality of the system

SE Fall 2002


Slide21 l.jpg

SE Fall 2002


Slide22 l.jpg

  • “Consists of” Association for Use Cases

  • Not explicitly named in UML

  • Problem: A function in the original problem statement is too complex to be solvable

  • Solution: Describe the function as the aggregation of a set of simpler functions. The associated use case is refined into smaller use cases

  • ManageIncident

  • CreateIncident

  • HandleIncident

  • CloseIncident

SE Fall 2002


Slide23 l.jpg

  • “Extends” Association for Use Cases

  • Problem: The functionality in the original problem statement needs to be extended.

  • Solution: An extends association from a use case A to a use case B indicates that use case B is an extension of use case A.

  • That is, the use case “ReportEmergency” is complete by itself , but can be extended by the use case “Help” for a specific scenario in which the user requires help

SE Fall 2002


Slide24 l.jpg

  • “Uses” Association for Use Cases

  • Problem: Need to reuse existing assets and resources

  • Solution: The uses association from a use case A to a use case B indicates that an instance of the use case A can perform all behavior described for the use case B

  • Example: The use case “ViewMap” describes behavior that can be used by use case “OpenIncident”

SE Fall 2002


Slide25 l.jpg

  • How to Specify a Use Case

  • Actors (Description of Actors involved in use case)

  • Entry condition (This use case starts when...)

  • Flow of Events (Free form natural language text)

  • Exit condition (This use cases terminates when...)

  • Special Requirements

SE Fall 2002


Slide26 l.jpg

  • Use Case Example: Allocate a Resource

  • Entry Condition

  • The use case starts after the Resource Allocator has selected an available Resource.

  • The Resource is currently not allocated

  • Flow of Events

  • The Resource Allocator selects an Emergency Incident.

  • The Resource is committed to the Emergency Incident.

  • Exit Condition

  • The use case terminates when the resource is committed.

  • The selected Resource is now unavailable to any other Emergency Incidents or Resource Requests.

  • Special Requirements

  • The Field Supervisor is responsible for managing the Resources

SE Fall 2002


Slide27 l.jpg

  • Heuristics: How do I find use cases?

  • Select a narrow vertical slice of the system (i.e. one scenario) and discuss it in detail with the user to understand the user’s preferred style of interaction

  • Select a horizontal slice (i.e. many scenarios) to define the scope of the system. Discuss the scope with the user

  • Use mock-ups as visual support

  • Find out what the user does

    • Task observation (Good)

    • Questionnaires (Bad)

SE Fall 2002


Slide28 l.jpg

  • Is there Life after Scenarios and Use Cases?

  • Functional Decomposition says yes

  • Every use case is refined into a set of lower level use cases

    • The use cases consists of lower level use cases

    • The use case is extended by another use case

  • This refinement is repeatedly done until the lowest level use cases are machine instructions that can be executed by the target machine

SE Fall 2002


Slide29 l.jpg

  • Problems with Functional Decomposition

  • High cost of recompilation

  • Adding a new device usually requires compilation of every file that uses the device

  • Leads to unmaintenable code

  • The better way is to start with functional decomposition and then to find objects

  • Object identification

  • Sequence Diagrams

SE Fall 2002


Slide30 l.jpg

Modeling a Briefcase

BriefCase

Capacity: Integer

Weight: Integer

Open()

Close()

Carry()

SE Fall 2002


Slide31 l.jpg

A new Use Case for a Briefcase

BriefCase

Capacity: Integer

Weight: Integer

Open()

Close()

Carry()

SitOnIt()

SE Fall 2002


Slide32 l.jpg

  • Questions

  • Why did we model the thing as “Briefcase”?

  • Why did we not model it as a chair?

  • What do we do if the SitOnIt() operation is the most frequently used operation?

  • The briefcase is only used for sitting on it during video conferences. It is never opened nor closed. Is it a “Chair”or a “Briefcase”?

  • How can we live with our mistake?

SE Fall 2002


Slide33 l.jpg

  • Summary

  • Requirements Engineering:

  • Greenfield Engineering, Reengineering, Interface Engineering

  • Scenarios:

  • Great way to establish communication with client

  • As-Is Scenarios, Visionary scenarios, Evaluation scenarios, Training scenarios

  • Use cases: Abstraction of scenarios

  • Pure functional decomposition is bad:

  • Leads to unmaintainable code

  • Starting with object identification is bad:

  • May lead to wrong objects, wrong attributes, wrong methods

  • The key to successful analysis:

  • Start with use cases and then find the participating objects

  • If somebody asks “What is this?”, do not answer right away. Return the question or observe: “What is it used for?”

SE Fall 2002


From bernd bruegge l.jpg
From Bernd Bruegge

  • CMU/Munich

  • Notes on Software Lifecycle

SE Fall 2002


Slide35 l.jpg

  • Engineering Complex Systems

  • Based on modeling: A model of a system describes a specific aspect of the system under consideration.

  • Main principles used in developing models

    • Abstraction

    • Decomposition

    • Hierarchy

    • Encapsulation

  • Terminology

    • Notation: Language to express each model

    • Process: Guidelines for the orderly construction of the models (SEI Capability maturity model - Humphrey)

    • Product: A description of a model

    • Tool: Artifact that supports the building of models and enforces rules about the models (completeness, consistency, unambiguity)

SE Fall 2002


Slide36 l.jpg

  • Hierarchy

  • Bring order into chunks (subsystems) obtained by abstraction and decomposition

  • Class (Object) identification

    • Attributes

    • Operations (Methods)

  • Define relations between classes

    • Called associations

  • 2 important hierarchies

    • "Part of" hierarchy

    • "Is-kind-of" hierarchy

We will also deal with aspect hierarchies

SE Fall 2002


Slide37 l.jpg

  • Other ways to deal with complexity

  • Start with an existing system

    • Use templates

  • Use techniques and tools

  • Build the system incrementally and iteratively

    • Use models

  • Use a Software development methodology

    • Software lifecycle

SE Fall 2002


Slide38 l.jpg

  • Categories of software development methodologies

  • Object-oriented methodology

  • Systems are modeled as a collection of cooperating objects

  • Structured Methodology

  • Based on functional (algorithmic) decomposition

  • Data-driven Methodology

  • Structure of system is derived by mapping system inputs to outputs.

  • E,g, Jackson System Development

  • Aspect-oriented Methodology

  • Support for crosscutting abstractions

  • E.g. Demeter, AspectJ, HyperJ

SE Fall 2002


Slide39 l.jpg

  • Models to Describe Systems

  • Greek Philosophers used two models to the universe:

  • Demokrit: Everything is composed of atoms

  • Heraklit: Everything flows (Panta Rhei: everything changes/moves)

  • A good software design methodology provides at least three models (Why not just two?):

  • Structural model:

    • What is the structure of the system?

    • What are the objects and how are they related?

  • Functional model:

    • What are the functions of the system?

    • How is data flowing through the system?

  • Control model

    • How does the system react to external events?

    • How is the event flow in the system ?

SE Fall 2002


Slide40 l.jpg

  • Software Development Methodologies

  • Structured Analysis (Yourdon and DeMarco, 1978)

  • Structured Design (Yourdon and Constantine, 1979)

  • OMT (Rumbaugh et al, 1991)

  • Object-Oriented Modeling Technique

  • Object model: What are the objects in the system?

  • Functional model: What are the functions of the system?

  • Dynamic model: How does the system react to external events?

  • Other object-oriented methodologies:

  • HOOD (European Space Agency, 1989)

  • CRC (Class, Responsibility & Collaboration, Wirfs-Brock, 1991)

  • OOA (Yourdon &Coad, 1991)

  • Booch method (Booch, 1991)

  • OOSE (Jacobson, 1992)

SE Fall 2002


Slide41 l.jpg

  • UML

  • UML (Grady Booch, Ivar Jacobsen and James Rumbaugh)

  • Structural Model:

    • Class Diagrams: Describes the structure of the system in terms of classes and objects

  • Functional Model:

    • Use Case Diagram: Describes the external behavior of the system from a functional point of view

  • Control Model:

    • Sequence Diagrams: Describes the dynamic interaction between objects identified in the structural model

    • Activity Diagrams: Describes the dynamic behavior of a single object

SE Fall 2002


Slide42 l.jpg

  • CASE (Computer Aided Software Engineering)

  • Automate and aid a particular activity

  • Use information from one activity to another one.

  • OMTool (Rumbaugh, 1991): A front end CASE tool only for class diagrams

    • X-based, C++ templates (skeleton code), Suns, HPs and PCs

  • Lifecycle CASE tools have an underlying model of system development that spans many activities: (dated information: 1997)

    • OTE: Object Team Enterprise, Cayenne Software, for OMT

    • StP/OMT: Software through Pictures, Interactive Development Environments, CASE for many methodologies

    • Objectory: Object Factory, Objectory, CASE tool for OOSE

    • ROSE: Rational, Case tool for the UML methodology

SE Fall 2002


Slide43 l.jpg

  • Methodology Definition

  • Methodology: A collection of techniques for building models - applied across the development of a software system (software life cycle)

SE Fall 2002


Slide44 l.jpg

  • Software Life Cycle

  • Software development goes through a progression of states (software development activities)

  • Conception

  • Childhood

  • Adulthood

  • Retirement

SE Fall 2002


Slide45 l.jpg

Examples of Software Development Activities (Pfleeger)

Requirements Analysis: What is the problem?

System Design:What is the solution?

Program Design: What are the mechanisms that best implement the solution.

Program Implementation: How is the solution constructed?

Testing: Is the problem solved?

Delivery: Can the customer use the solution?

Maintenance: Are enhancements needed?

Problem

domain

Implementation

domain

SE Fall 2002


Slide46 l.jpg

  • Software Lifecycle

  • Definition:

  • Set of activities that constitute a software project

  • Typical Lifecycle questions:

  • Which activities should I select for the software project?

  • What are the dependencies between activities?

  • How should I schedule the activities?

SE Fall 2002


Slide47 l.jpg

  • Inherent Problems with Software Development

  • Requirements are constantly changing

    • The client does not know them in advance

  • Frequent changes are difficult to manage

    • Identifying checkpoints for planning and cost estimation is difficult

  • Phased Development

    • New system must be backward compatible with existing system

    • There must be a distinction between the system under development and the already released systems

SE Fall 2002


Slide48 l.jpg

  • Life-Cycle Model: Variations on a Theme

  • Many models have been proposed to deal with the problems of defining activities and associating them with each other

  • The waterfall model

  • First described by Royce in 1970

  • There seem to be at least as many versions as there are authorities - perhaps more

SE Fall 2002


Slide49 l.jpg

The Waterfall Model of the Software Life Cycle

Requirements Analysis and Definition

System and Software Design

System Testing

Implementation and Unit Testing

SE Fall 2002


Slide50 l.jpg

  • Problems with Waterfall Model

  • Managers love waterfall models:

  • Nice milestones

  • No need to look back (linear system)

  • Always one activity at a time

  • Easy to check progress during development: 90% coded, 20% tested

  • However, software development is iterative

  • While a design is being developed, problems with requirements are identified

  • While a program is being coded, design and requirement problems are found

  • While a program is tested, coding errors, design errors and requirement errors are found

SE Fall 2002


Alternative l.jpg
Alternative

  • Allow iteration

SE Fall 2002


Slide52 l.jpg

Alternative Lifecycle Model: Allow Iteration

Revise, Review -> List of revisions for each phase

Requirements (inconsistent, incomplete, ambiguous)

Phases:

Requirements Elicitation

Analysis

Design

Implementation

Testing

Delivered System

SE Fall 2002


Slide53 l.jpg

  • Spiral Model (Boehm)

  • Identify risks

  • Assign priorities to risks

  • Develop a series of prototypes for the identified risks starting with the highest risk.

  • Use a waterfall model for each development (round or cycle)

  • If a risk has successfully been resolved, evaluate the results of the round and plan the next round

  • If a certain risk cannot be resolved, terminate the project immediately

SE Fall 2002


Slide54 l.jpg

  • Activities (“Rounds”) in Boehm’s Spiral Model

  • Concept of Operations

  • Software Requirements

  • Software Product Design

  • Detailed Design

  • Code

  • Unit Test

  • Integration and Test

  • Acceptance Test

  • Implementation

  • For each round go through these steps

  • Define objectives, alternatives, constraints

  • Evaluate alternative, identify and resolve risks

  • Develop, verify next level product

  • Plan next activity (“round”, “phase”)

SE Fall 2002


Slide55 l.jpg

  • Different Types of Prototypes

  • Illustrative Prototype

  • Develop the user interface with a set of storyboards

  • Implement them on a napkin or with a user interface builder (Visual C++, ....)

  • Good for first dialog with client

  • Functional Prototype

  • Implement and deliver an operational system with minimum functionality

  • Then add more functionality

  • Order identified by risk

  • Exploratory Prototype ("Hacking")

  • Implement part of the system to learn more about the requirements.

  • Good for paradigm breaks

SE Fall 2002


Slide56 l.jpg

  • Types of Prototyping cont’

  • Revolutionary Prototyping

  • Also called specification prototyping

  • Get user experience with a throwaway version to get the requirements right, then build the whole system

  • Disadvantage: Users may have to accept that features in the prototype are expensive to implement

  • User may be disappointed when some of the functionality and user interface evaporates because it can not be made available in the implementation environment

  • Evolutionary Prototyping

  • The prototype is used as the basis for the implementation of the final system

  • Advantage: Short time to market

  • Disadvantage: Can be used only if target system can be constructed in prototyping language

SE Fall 2002


Slide57 l.jpg

  • Prototyping vs Rapid Development

  • Revolutionary prototyping is sometimes called rapid prototyping

  • Don't confuse prototyping with rapid development

  • Prototyping is a technical issue: It is a particular model in the life cycle process

  • Rapid development is a management issue. It is a particular way to control a project

  • Prototyping can go on forever if it is not restricted

  • “Time-boxed” prototyping

SE Fall 2002


Slide58 l.jpg

  • Class vs Project

  • In class, we will introduce software development activities in a certain order constrained by the lectures schedule

  • In the project, we must be able to deal with iteration, out of order activities, revisions and refinements (based on new information obtained during the project)

  • Your goal:

  • Learn about the software development activities

  • Gain a better understanding of the difficulties of the software development

  • Combine the current state of the art knowledge with tools and techniques to produce a quality software system delivered in time and within budget.

SE Fall 2002


Slide59 l.jpg

  • Standards for Software Development

  • IEEE (Institute of Electrical and Electronics Engineers)

  • IEEE Standards:

  • IEEE 1074-1995: Software Lifecycle

  • IEEE 1058.1-1987: Project Management

  • IEEE 1042-1987: Configuration Management

  • OMG (Object Management Group): Committed to provide software connectivity across heterogeneous platforms and languages

  • CORBA (Common Object Request Broker Architecture)

SE Fall 2002


Slide60 l.jpg

  • IEEE Software Engineering Standards

  • Other important standards

  • IEEE 610 Glossary of Software Engineering Terminology

  • IEEE 830 Guide for Software Requirements Specification

  • IEEE 1002 Standard Taxonomy for Software Engineering Standards

  • Standards are rapidly changing and are revised every couple of years

  • Revisited every 5 years

  • Standards older than 5 years: Reasonable to assume that the present state is not wholly reflected

SE Fall 2002


Slide61 l.jpg

  • Other Standards

  • ISO (International Standard Organization)

  • OSI Hierarchy (Open System Interconnection)

  • EDI standard (for electronic data interchange)

  • ISO 9001 (Standard for Software Development)

  • CCITT (International Consultative Committee on Telephony and Telegraphy)

  • A group composed of the world's telecommunication companies

  • X.25 Standard for packet-switched network layer services

  • X.400 Message Handling

  • X. 500: Directory Standard

  • ANSI (American National Standards Institute)

  • Official Representative of the US to ISO and CCITT

  • ASCII

SE Fall 2002


Slide62 l.jpg

  • Processes, Activities and Tasks IEEE 1074

  • Processes consists of Activities which in turn consist of tasks

  • Example:

  • The Design Process consists of the following Activities

  • Perform Architectural Design

  • Design Database (If Applicable)

  • Design Interfaces

  • Select or Develop Algorithm (If Applicable)

  • Perform Detailed Design (= Object Design)

  • The Design Database Activity has the following Tasks

  • Review Relational Databases

  • Review Object-Oriented Databases

  • Make a Purchase recommendation

  • ....

SE Fall 2002


Slide63 l.jpg

  • Software Development Activities in COM 3205

  • Focus on Development

  • Planning

  • Requirements Analysis

  • Design

  • System Design

  • Object Design

  • Implementation

  • Coding

  • Unit Testing

  • Integration Testing

  • System Testing

  • System Delivery

SE Fall 2002


Slide64 l.jpg

  • Software Process Model used in COM 3205

  • Activities: Planning, Requirements Analysis, System Design, Object Design, Unit Testing, Integration Testing, System Testing, Delivery

  • Iterative Lifecycle model:

  • Called Micro/Macro Model by Booch

  • A lot of iterations during a particular software development activity (micro iteration)

  • Zero or more iterations across activities (macro iteration)

  • Build at least two prototypes

  • Illustrative prototype

  • Functional Prototype

  • Time-boxed prototyping

  • Every activity has a start and termination date

SE Fall 2002


Slide65 l.jpg

  • Roles in COM 3205

  • Software development roles (every student)

  • Analyst, Designer, Programmer, Tester

  • Management roles (every student)

  • Project leader

  • API Engineer (Architecture Team Liaison)

  • HCI Engineer (HCI Team Liaison)

  • Configuration manager

  • CASE Modeler

  • Web Master

  • Planner

SE Fall 2002


Slide66 l.jpg

  • Requirements Analysis

  • Analyze, understand and record the problem that the client is trying to solve (given in the problem statement)

  • Define the system

  • Specify the boundaries of the systems

  • Specify the goals and constraints

  • Specify the use cases (use case model)

  • Specify the object, functional and dynamic model

  • Client and developer must agree on the specification (requirements analysis document) which is used as the basis for the design

SE Fall 2002


Slide67 l.jpg

  • Design

  • Create a solution that meets the specifications outlined in the requirements analysis phase

  • Design is a complex process and highly iterative

  • Parts of the design

  • User interface design : Design of the system as it will be seen by the users (end user, maintainer, client)

  • System design: Define the structure of the system, that is, its modular components and the relationship among the components

  • Object design: Make decisions about implementation of each of the components (signature: type of parameters and return results)

SE Fall 2002


Slide68 l.jpg

  • Boundary between Analysis and Design

  • Boundary between analysis and design is vague, but certain guidelines for what should be described during analysis and what should be dealt with during construction

  • Analysis is application-oriented

  • Analysis is independent of the implementation environment

  • Analysis model describes the elements of the application as service modules

  • Analysis model should not be too elaborate, as some of this work must be adapted to the chosen implementation environment

SE Fall 2002


Slide69 l.jpg

  • Implementation

  • Major product of this phase is the source code

  • 3 activities: Coding, unit testing and integration testing

  • Coding: Write the source code for some component of the system

  • Unit testing: Subject component to a number of tests for reliability and validity

  • Integration testing: Test groups of unit-tested components according to an integration strategy.

SE Fall 2002


Slide70 l.jpg

  • System Testing

  • Entire software system is subject to a variety of tests (Alpha testing: Acceptance test at developer site).

  • Major goal is to make sure all components created and tested during implementation function together as a system.

  • Question: Is the problem solved?

  • Verification: Are we building the product right?

  • Validation: Are we building the right product?

  • Tests whether the product works as intended. Requires careful planning and coordination.

SE Fall 2002


Slide71 l.jpg

  • Delivery

  • Time during development when we help the users to understand and feel comfortable with the product

  • Question to ask: Can the customer use the solution?

  • Documentation:

  • Developer Documentation

  • User Documentation

  • Administrator Documentation

  • Operator Documentation

SE Fall 2002


Slide72 l.jpg

  • Maintenance

  • System development is complete when the system is operational in its intended environment.

  • Any work done that changes the system after it is in operation is considered maintenance.

  • Question to ask: Are enhancements needed?

  • Maintenance is not repair or prevention of breaks:

  • Loop constructs do not wear out!

  • Software does not degrade

  • Software systems are built to incorporate change.

SE Fall 2002


Slide73 l.jpg

  • Summary

  • Software life cycle

  • The development process is broken into individual pieces called software development activities

  • No good model for modeling the process (black art)

  • Existing models are an inexact representation of reality

  • Nothing really convincing is available

  • Software development standards

  • IEEE

  • MIL

  • Standards help, but must be taken with a grain of salt

  • What are we using in COM 3205: Agile Software Development

SE Fall 2002



Communication l.jpg

Communication

Bernd Bruegge

SE Fall 2002


Communication is important l.jpg
Communication is important

  • A Communication Example

  • "Two missile electrical boxes manufactured by different contractors were joined together by a pair of wires.

  • Pair of Wires

  • Box 1

  • Box 2

SE Fall 2002


Slide77 l.jpg

  • A Communication Example ctd

  • Thanks to a particular thorough preflight check, it was discovered that the wires had been reversed.“

  • Box 1

  • Box 2

SE Fall 2002


Slide78 l.jpg

  • After the Crash...

  • "The postflight analysis revealed that the contractors had indeed corrected the reversed wires as instructed.“

  • Indeed, both of them had.

SE Fall 2002


Slide79 l.jpg

  • Communication is Important

  • Communication Mode:

  • Type of information exchange that has defined objectives and scope

  • Scheduled: Planned Communication

  • Event Driven:Unplanned Communication

  • Communication Mechanism

  • Tool or procedure that can be used to transmit or receive information

  • Synchronous: Sender and Receiver are available at the same time

  • Asynchronous: Sender and Receiver are not communicating at the same time.

SE Fall 2002