User:Hyad/SE/Test1

Activity Management

• Identifying what needs to be done
• Planning and scheduling activities
• Assigning responsibilities for activities
• Tracking them to completion

Requirements

• Requirements must be determined OR Clients produce requirements
• New development (green field project) OR Evolution of existing system

Software Process Models

(Lifecycle models) http://www.se.rit.edu/~se361/slides/SoftwareProcessModels.pdf

-models should be aids ot thinking; not rigid

Opportunistic approach

• First Prototype --> Modify until satified <--> Think of Idea for improvement
• OK for small projects, bad for big ones

Waterfall

-classic SE model

• Requirements gathering & Definiton

-->Specification -->Design -->Implentmentation -->Integration & Development -->Maintenance

• Good: emphasizes importance of requirements, design, quality insurance
• Bad:Must complete one stage before next, doesn't allow prototyping, testing is done only at end, it implies after product is finished-everything els eis just maintenance

Incremental

• Requirements-->Design-->Implentmentation-->Testing, then you're done with Ver. 1
• Requirements-->Design-->Implentmentation-->Testing, then you're done with Ver. 2...
• Good:Customers provide feedback after each release, core functionality developed early on

Spiral

--risk driven

Requirements

http://www.se.rit.edu/~se361/slides/Requirements.pdf

Domain

-get a better understanding of your domain

• The domain is the general field of business or technology in which

the clients will use the software

• A domain expert is a person who has a deep knowledge of the

domain

Requirement

• Requirement: A statement about the proposed system that

all stakeholders agree must be made true in order for the customer’s problem to be adequately solved.

• Short and concise piece of information
• Says something about the system
• All the stakeholders have agreed that it is valid
• It helps solve the customer’s problem
• A collection of requirements is a requirements document.

Functional requirements

-Describe what the system should do

• What inputs the system should accept
• What outputs the system should produce
• What computations the system should perform

Non-functional requirements

-Constraints that must be adhered to during -3 types:

• 1. Product properties: usability, efficiency, reliability,

maintainability and reusability

• 2. Constraints on the platform and technology to be used
• 3. Constraints on the project plan & development methods

development ex. Cost

User Stories

• Identify the various operations performed by users on

the system

• Develop a brief narrative description of the steps

involved in each operation and the system responses

Types of Requirements Documents

• Requirements documents

for large systems are normally arranged in a hierarchy

• Requirements definition-

An informal outline of the requirements using a few paragraphs or simple diagrams

• Requirements specification-

A long list of specifications that contain hundreds of pages of intricate detail

• Requirements analysis never stops

Risk

• Requirements risk: Missing key requirements and preferences that

impact customer satisfaction

• Technical risk: Not sure if the product will be able to deliver on

functionality / performance / convenience

• Technology risk: Will the team be able to use the development

technologies properly? (if new technologies being used)

• Design risk: Missing key design issues / wrong decisions
• Market risk: Will it sell? Will customers like it?
• Schedule risk: Will it get completed on time?

Prototyping and Risk

http://www.se.rit.edu/~se361/slides/Prototyping&Risk.pdf

Prototyping

• The simplest kind: paper prototype.
• a set of pictures of the system that are shown to users in

sequence to explain what would happen

• The most common: a mock-up of the system’s UI
• Written in a rapid prototyping language
• Does not normally perform any computations, access any

databases or interact with any other systems

• May prototype a particular aspect of the system
• Prototyping involves building simple & quick

implementations of parts of the product

• The major reason for prototyping is to reduce some type of

risk associated with the project

Several types of prototypes, depending on objectives

• Interface prototypes (most common) mitigate requirements risk
  • Build a mockup of product interface to get user feedback
  • Minimal or dummy functionality
• Implementation prototypes mitigate technical risk
  • Core product functionality to demonstrate feasibility of product
  • May have trivial interfaces and few additional features
  • Variation: Design prototypes, to understand design issues, study behavior
• Technology prototypes try out use of new technologies
  • Build only a part of the product, or even something totally different
• Demos are prototypes built to mitigate market risk

Types of Prototypes

• Throw away prototype
  • Discard prototype, build product from scratch

+ Can use special “prototyping technologies” to build quick prototypes e.g. GUI builders, code generators + Don’t have to design prototype carefully + Coding can be more freestyle and unconstrained – Need to redo all the work

• Evolutionary Prototypes
  • Modify prototype into final product

+ Prototype is just first version in incremental development • But need to be careful to use full product-style development process when building prototype – Prototypes change a lot early on, so design & code quality may deteriorate. Need to re-factoring /reimplementation as needed

• Prototyping for elicitation of requirements (Demo)
  • Advantage: Customer knows exactly what to expect
  • Danger: Customers don’t know why it takes so long to go from prototype to product!

---

Software Engineering Practices

http://www.se.rit.edu/~se361/slides/SEpractices.pdf

1.Activity Management

• Identify the activities involved in the project
  • Based on the modules/features that need to be

developed

• • Include lifecycle activities: design, inspections, testing,

customer reporting and presentations…

• Create a project plan
• Estimate effort involved and completion time
  • To make commitments to customer
  • To arrange for resources
  • Refine estimates based on past experience (estimated/actual) - Underestimation of effort is extremely common
• Track the activities through to completion

2.Risk Management

� Identify list of risks at the beginning of project � Estimate “probability of occurrence”: how likely is it? � Estimate impact: how much will it affect the project? � Prioritize based on combination of probability & impact � Risk mitigation is only worthwhile for a few high priority risks � Involves investing extra effort now, so that the probability of risk occurrence is reduced, or so that the impact will be less if it occurs � Risks must be constantly tracked: checked to see if they have occurred and need handling, and whether new risks have arisen � Assign owner who is responsible for tracking the risk periodically and ensuring mitigation strategies have been implemented

3.Configuration Management

• Manage concurrent modifications to files
  • CM tools have check-out / check-in concept
  • Check-in comments to provide history of changes
• Concept of workspaces provides consistent view for builds
  • Others cannot build if you check in file with errors
  • CM tools provide individual workspaces for team members.
  • Check in only after fully developing and unit testing the module.
  • The shared workspace only has consistent versions of files
• Cannot rely solely on tool to prevent all problems
  • Also need coordination between team members to make sure that features added to different modules work together

• CM tools support “branching” – multiple concurrent lines of development
  • Useful if developing for multiple platforms
  • Also if delivering slightly customized versions to different customers

4.Quality Management and Processes

Processes

• Systematic series of steps to accomplish a task well
• Represents “most effective way of doing task that will avoid future problems”
• Example: Code inspection process (abbreviated version)
  • Arrange meeting and notify people
  • Send out doc to be reviewed at least 2 days before meeting
  • Participants must come to meeting prepared with lists of defects found
  • Have a moderator and recorder (to keep track of defects found) – there

may also be other roles

• • For each problem found, discuss briefly if it is really a problem
    • “Accept” or “Reject” the bug, record information about it
  • After the meeting, fix the problems, and track its fixing
• You can see that it is designed to avoid common problems: people coming inunprepared, open-ended discussions, bugs found but never fixed etc.

Quality Management

• Finding best possible way to get work done
  • More efficient ways to accomplish tasks that save effort overall
  • Ways to work that improve quality of results from task
• Example: Inspections and reviews are known to be excellent quality practices
  • (say)5 people spend 2 hours each reviewing 500 lines of code, and

find 6 defects & improvement opportunities

• • To find those defects through testing, then debugging, fixing them

and retesting would take (say) 30 hours

• • We spend 10 hours to save 30
  • Incidental benefits: Familiarity with others’ code, in case they are unavailable; learn from each other; avoid mistakes in own code

• Defining good processes that avoid problems
• Coding standards, to enhance readability & maintainability and

improve consistency of coding practices in team

• Document templates, to
  • Provide clear guidance on what to document
  • Save effort creating documents from scratch
  • Avoid forgetting important information content
• Checklists, for checking that everything has been done
• Tracking inspection & test problem reports to closure
• Using metrics data to improve estimation accuracy, identify common bugs to be avoided etc.

Defining Appropriate Practices

The processes and quality practices chosen must be matched to the needs of the project

• Large complex projects require more formal processes
• Larger teams need more activity management
• Geographically distributed teams need stronger configuration management, more formal processes and rigorous activity management
• Business-critical and “risky” projects (more high probability high impact risks) need more risk management