ITEC 4010

Lecture
Click to edit Master 2 –styles
text Initiation and Analysis, Estimation, Development
Principles and Mistakes
Second level
Third level
Fourth level
Fifth level

1
 System Development Project

• Project:
• A planned undertaking that has a beginning, and end, and which produces a predetermined
result or product
• Usually specified in terms of cost, schedule, and performance requirements

• System development project:

• Planned undertaking that produces an information system

2
 Project Matters (components)

• Work product: Any item produced by the project as a result of a task

• E.g. piece of code
• Model
• Document
• Etc…
• Usually takes the form of a deliverable

• Schedule:
• A list of a project’s milestones, activities, and deliverables with intended start and
finish dates

• Participant:
• Any person participating in a project
• Are considered stakeholders

• Task:
• Work to be performed by a project participant to create a work product
3
 Project Matters (communications)

• Planned communications:
• Help to disseminate information that targeted participants are expected to use
• Problem inspections:
• Gathering information from the problem statements, the clients, and/or users
about their needs and application domain
• Status meetings:
• Review the progress of the project team
• Peer reviews:
• Reviews by team members to identify defects and find solutions in preliminary
project products
• Client and project reviews:
• Reviews by the client or project member(s) to review the quality of a
deliverable
• Releases:
• Project participants/team make available to the client/users a version of the
system and its documentation

4
 Project Matters (components)

• Unplanned communications:
• Help to deal with crises and unexpected information needs
• Request for clarification: project participant requests specific information from
others about the system, application domain, or the project
• Request for changes: participant describes problems encountered in the system or
new features that the system should support
• Issue resolution: to identify a conflict between different stakeholders, explore and
negotiate solutions and agree upon a resolution

5
 Project Matters (organization)

• Team-based organization

• Team: small set of participants working on the same activity or task

• E.g. management team, user interface team, database team, network team, application team,
control team, etc…

• Project interactions:
• Reporting: to report status information
• Decision: to propagate a decision (rule)
• Communication: to exchange all other types of information needed for decision or status
reporting

6
 System Development Life Cycle (SDLC)

• 5 Core Phases:

7
 System Development Life Cycle (SDLC)

• Initiation:

8
 Initiation: Origin/Source

• Projects may be initiated as part of the long-term strategic plan (top-down)

• based on mission or objective statement
• produce some competitive business strategy

• Projects may proceed bottom up

• To fill some immediate need that comes up

• Projects may also be initiated due to some outside force

• E.g. change in tax structure may affect billing system

9
 Defining the Problem

• Review business needs and benefits

• Identify the expected capabilities of the new system

• May involve developing a context diagram to explain the scope of the project

• Begin preliminary requirements elicitation

10
 Statement of Need

11
 High-Level Overview of System Capabilities

12
 System Vision Document

• Problem description

• System capabilities

• Business benefits

13
 Project Schedule

1. Identify individual tasks for each activity

• Top-down or bottom-up approach

2. Estimate the size of each task (time and resources) – optimistic, pessimistic and
expected times

3. Determine the sequence for the tasks

4. Schedule the tasks

• Charting methods
• PERT/CPM (Project Evaluation and Review Technique/Critical Path Method) chart
shows the relationships based on tasks or activities
• Defines tasks that can be done concurrently or not and critical path
• Gantt chart shows calendar information for each task as a bar chart
• Shows schedules well but not dependencies as well

14
 Overlap of systems development activities in
scheduling

15
 Project Schedule – Task List

16

16
 Project Team/Members

• Project team varies over duration of the project

• During planning, team consists of few members
• Project manager, analysts
• During analysis, team adds systems analysts, business analysts
• During design, other experts may come in with technical expertise
• E.g. Database specialists
• Network specialists
• During implementation, programmers and quality control specialists are
added

17
 Project Team/Members

• Figure: Staffing levels of a typical IT project

18
 PERT Chart

• Tasks Represented by rectangles

• Tasks on parallel paths done concurrently

• Critical path = longest path of dependent tasks

• No allowable slack time on this path
• Other paths can have slack time

19
 PERT Chart

• Tasks Represented by rectangles

• Tasks on parallel paths done concurrently

• Critical path = longest path of dependent tasks

• No allowable slack time on this path
• Other paths can have slack time

20
 Gantt Chart

• Tasks represented by vertical bars

• Vertical tick marks are calendar days and weeks

• Shows calendar information in a way that is easy

• Bars may be colored or darkened to show completed tasks

• Vertical lines indicates today’s date

21
 Gantt Chart

• Tasks represented by vertical bars

• Vertical tick marks are calendar days and weeks

• Shows calendar information in a way that is easy

• Bars may be colored or darkened to show completed tasks

• Vertical lines indicates today’s date

22
 Staffing a Project

• Develop a resource plan

• Identify and request technical staff
• Identify and request specific user staff
• Organize the project team into work groups
• Conduct preliminary training and team-building

23
 Feasibility Studies

Confirming Project Feasibility

• Economic feasibility – cost-benefit analysis
• Organizational and cultural feasibility
• E.g. low level of computer literacy, fear of employment loss
• Technological feasibility
• Proposed technological requirements and available expertise
• Schedule feasibility
• Fixed time or deadline?
• Resource feasibility
• Availability of team, computer resources, support staff

24
 Economic feasibility study

• Each category of cost is estimated

• Salaries and wages are calculated based on staffing requirements

• Other costs such as equipment, software licenses, training are also estimated

• A summary of development costs and annual operating costs is created

• A summary of benefits is created

• Net present value (NPV) – present value of benefits and costs, is calculated for e.g.
5 year period

25
 Cost-Benefit Analysis

• Costs

• Development costs : salaries and wages, equipment and installation,

software and licenses, consulting fees and payments to third parties, training,
facilities, utilities and tools, support staff, travel and miscellaneous

• Sources of Ongoing Costs of Operations: connectivity, equipment

maintenance, computer operations, programming support, amortization of
equipment, training and ongoing assistance (help desk), supplies

26
 Cost-Benefit Analysis

• Benefits
• Tangible benefits - examples
• Reducing staff (due to automation)
• Maintaining constant staff
• Decreasing operating expenses
• Reducing error rates (due to automation)
• Ensuring quicker processing and turnabout
• Capturing lost discounts
• Reducing bad accounts or bad credit losses
• Reducing inventory or merchandise loss
• Collecting accounts receivable more quickly
• Capturing income lost due to “stock outs”
• Reducing the cost of goods with volume discounts
• Reducing paperwork costs
27
 Cost-Benefit Analysis

• Benefits
• Intangible benefits – examples
• Increased level of service (in ways that can’t measure)
• Increased customer satisfaction
• Survival
• The need to develop in-house expertise

Note - also can have intangible costs for a project

• reduced employee moral
• lost productivity
• lost customer or sales

28
 Cost-Benefit Analysis

• Net Present Value (NPV) – Present value of benefits and costs

• Cumulative NPV – Calculated value of benefits and costs over a certain time
period

29
 Further Planning Preparations

• Staffing the project:

• Develop a resource plan
• Identify and request technical staff
• Identify and request specific user staff
• Organize the project into work teams
• Conduct preliminary training and team-building

• Launching the project:

• Oversight committee/Executive stakeholders give final go-ahead
• Funds are released and the project is announceed.

30
 Software Estimations as a Process of Refinement

• Some organizations want estimates within +-10% before they start

• Most projects overshoot their estimated schedules by 25% to 100%

• You refine your estimates at each of the project’s stages:

• Requirements documentation
• Preliminary/Architectural Design
• Detailed Design
• Working code

• Uncertainty about the nature of the product contributes to uncertainty in the

estimates

31
 Sources of uncertainty (single feature)

• Will the customer want feature X?

• Will the customer want the cheap or expensive version of feature X?

• If you implement the cheap version of feature X, will the customer later want
the expensive version after all?

• How will feature X be designed?

• What will be the quality level of feature X?

• How long will it take to debug and correct the mistakes made in the
implementation of feature X?

• How long will it take to integrate feature X with all the other features?

32
 Estimate-convergence graph

Figure. Estimate-convergence graph. Optimistic and

Pessimistic effort estimates are shown

33
 Estimate Multipliers

Estimate multipliers by project phase

34
 Estimation Techniques

• Size estimation:
• Algorithmic approach
• Utilizes program size from description of program features
• Mainly relies on similar completed projects and experience to determine size

• Function-Point estimation
• A kind of size estimation often used in a project’s early stages
• Based on counting:
• Inputs – screens, forms, dialog boxes, controls, etc…
• Outputs – screens, reports, graphs, etc.
• Inquiries – Input/output combinations
• Logical internal files – files controlled by the program
• External interface files – files control by other programs

35
 Estimation Techniques

• Effort estimation
• Once you have the size estimate you can derive the effort estimate
• Can convert size estimate (e.g. lines of code or number of functions) to effort
estimate
• Based on an organization’s historical data in terms of efficiency to determine
how much effort previous projects of an estimated size took

36
 Estimation Techniques

• Schedule estimation:
• Schedule estimation can be derived from effort estimation

• ie: schedule in months =

• Schedule = efficiency * effort

37
 General Development Principles and Mistakes

• Success of software development:

• Hinges on:
• Choosing effective practices rather than ineffective practices

• Choosing practices that are oriented specifically toward achieving your

schedule objectives

38
 General Development Principles and Mistakes

39
 General Development Principles and Mistakes

• Three types of schedule-oriented practices

Practices that improve development speed, allowing you to deliver software faster

Practices that reduce schedule risk, allowing you to avoid huge schedule overruns

Practices that make progress visible, allowing you to dispel the appearance of slow
development

40
 General Development Principles and Mistakes

• General Development Strategies

• Avoid classic mistakes

• Apply development fundamentals

• Manage risks to avoid catastrophic setbacks

• Apply schedule-oriented practices:

• Speed oriented
• Schedule risk reduction oriented
• Visibility oriented

41
 General Development Principles and Mistakes

• Provide support (as “four pillars”) for the best possible application development
• Classic Mistake Avoidance, Development Fundamentals, Risk Management,
Schedule-oriented practices

42
 General Development Principles and Mistakes
• Four dimensions of development speed:
• People
• Process
• Product
• Technology

43
 General Development Principles and Mistakes
• The People Dimension:
• People issues have more impact on software productivity than any other factor
• The most effective practices leverage human potential of developers
• Individual ability, individual motivation, team ability, and team motivation dwarf
other productivity factors

• Variations in productivity based on experience:

Greater than 10-to-1 differences in productivity among individuals with different
depths and breadths of experience
10-to-1 differences in productivity among individuals with the same levels of
experience
5-to-1 differences in productivity among groups with different levels of
experience
2.5-to-1 differences in productivity among groups with similar levels of
experience

44
 General Development Principles and Mistakes
• Process dimension:
• “Process” includes both management and technical methodologies
• Including:
• Rework avoidance (process should avoid repetition)
• Quality assurance
• Risk management
• Resource targeting
• Lifecycle planning
• Customer orientation

45
 General Development Principles and Mistakes
• Product dimension:
• If you can reduce a product’s feature set you can reduce the product’s schedule

• “80% of the product takes only 20% of the time”

• Effort required to build software increases disproportionately faster than the size
of the software
• Product characteristics (quality requirements) can take disproportionate
amounts of time to achieve

46
 General Development Principles and Mistakes
• Technology dimension:
• Changing from less effective tools to more effective tools can be a fast way to
improve development speed
• E.g. the change from low-level languages to high-level languages
• Choosing tools effectively and managing the risks involved are important

47
 General Development Principles and Mistakes
• Classic Mistakes: People

1. Undermined motivation
Motivation has biggest effect on productivity

2. Weak Personnel
Has next most important influence on productivity

3. Uncontrolled Problem Employees

4. Heroics
Encourages too much risk taking

5. Adding people to a late project

Like “pouring gasoline on a fire”

6. Noisy crowded offices

48
 General Development Principles and Mistakes
• Classic Mistakes: People

7. Friction between developers and customers

Customers may not think developers are delivering and developers may think
customers are unreasonable

8. Unrealistic expectations

9. Lack of effective project sponsorship

Projects need high level support

10. Lack of stakeholder buy-in

Need complete buy-in from all stakeholders

11. Lack of user input

Standish group found #1 reason projects succeed is user involvement

12. Politics placed over substance – can be fatal

“politicians”,”researchers”,”isolationists”,”generalists”

13. Wishful thinking –e.g. “we could pull it off ”

49
 General Development Principles and Mistakes
• Classic Mistakes: Process

14. Overly optimistic schedules

15. Insufficient risk management

16. Contractor failure

17. Insufficient planning

18. Abandonment of planning under pressure

19. Wasted time during the fuzzy front end

Time before project really gets off the ground

50
 General Development Principles and Mistakes
• Classic Mistakes: Process

20. Shortchanged (undervalued) upstream activities

Since requirements analysis, architecture and design don’t directly produce
code often shortchanged

21. Inadequate design

22. Shortchanged quality assurance

23. Insufficient management controls

24. Premature or overly frequent convergence

25. Omitting necessary tasks from estimates

26. Planning to catch up later

27. Code-like-hell programming

51
 General Development Principles and Mistakes
• Classic Mistakes: Product

28. Requirements gold-plating

Projects with more requirements than they need

29. Feature creep

Average project experiences about 25% increase in requirements over time

30. Developer gold-plating

Developers trying out new features

31. Push-me, pull-me negotiation

Completely behind schedule but then add new tasks when change schedule!

32. Research-oriented development

52
 General Development Principles and Mistakes
• Classic Mistakes: Technology

33. Silver-bullet syndrome

Too much reliance on previously unused technology

34. Overestimated savings from new tools or methods

Benefits from new tool can be offset by learning curves

35. Switching tools in the middle of a project

E.g. switching versions or even tool used for coding

36. Lack of automated source-code control

If done manually may easily get out of sync

53
 System Development Life Cycle (SDLC)

• 5 Core Phases:

54
 The Activities of the Analysis Phase

55
 Gathering Information

• Can get information from people who will be using the system
• By interviewing them
• By observing them
• Can get other information by reviewing documents and policy statements
(e.g. At a bank)
• Can involve the analyst actually doing some or part of the task to get a feel
for what is done
• In order to automate order-entry you may need to become an “expert”
on the task (knowing how orders are processed)
• Need to understand current and future users, locations, system interfaces,
possible solutions, etc.

56
 Gathering Information

• Example techniques:
• Interviewing users and other stakeholders
• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions

57
 Stakeholders

• Who do you involve? Who do you talk to?

• Stakeholders: people who have an interest in the successful implementation
of the system
• Internal Stakeholders: people within the organization
• External Stakeholders: people outside the organization
• Operational Stakeholders: people who regularly interact with the system
• Executive Stakeholders: people who don’t directly interact but do use the
information or do have a vested interest (usually financial)
• Internal/External and Operational/Executive are not mutually exclusive

58
 Stakeholders
• For an accounting system for a large public company:

59
 User Stakeholders
• Can identify users horizontally – i.e. Across departments
• How does one department affect another?

• Can also identify users vertically – i.e. Hierarchy within a department (e.g. lower,
middle and upper managers)
• How does one user role affect those above or below?
• Business operation -> management -> executive

• Type of users
• Business operations users – use the system daily to perform operations
(transactions – a piece of work)
• Query users – could be business people or customers – request info
• Management users – want reports, performance stats, want to know
volumes of transactions etc.
• Executive users – want information to help with strategic issues, e.g.
compare improvements in resource utilization

60
 Interviewing Users and Other Stakeholders
Time-consuming and resource-expensive.

Systems analysts do the following:

• Prepare detailed questions

• Meet with individuals or groups of users

• Obtain and discuss answers to the questions

• Document the answers

• Follow up as needed in future meetings or interviews

61
 Interviewing Users and Other Stakeholders

62
 Interviewing Users and Other Stakeholders
• Behaviour and activity checklist:

63
 Interviewing Users and Other Stakeholders
• Sample Session

64
 Documentation

• Elicitation produces information that must be documented

• When documenting or specifying requirements

• Missing information or gaps in the requirements may be detected
• Return to elicitation

• Conflicting statements from different stakeholders might be detected

• Requires negotiation

• Documentation and specification utilizes natural language

65
 Importance of Documentation

• Persistence
• Large amounts of information
• Stakeholders involved can hardly memorize or reflect on all this information

• Common reference
• Common reference point for all stakeholders involved

• Promotes communication
• Common reference promotes discussion about the requirements

• Promotes objectivity
• Exchange of information via documents is less amenable to unwanted alteration of the
information or subjective interpretation
• E.g. broken telephone

66
 Importance of Documentation

• Supports training of new employees

• Documented information provides excellent basis for new stakeholders to become
familiar with a project
• Stakeholder can selectively access relevant information

• Preserves expert knowledge

• Not all stakeholders involved know all relevant aspects of a system
• Includes technology or context
• Documentation of such knowledge makes it available to all project participants
• Reduces dependence on individual experts

• Helps to reflect on the problem

• The process of documentation information forces the author to structure the
information
• Structuring the information helps the author reflect on the information, which
leads to identification of gaps and inconsistencies

67
 Documentation vs Specification

• Documentation:
• Varying formats and levels of detail
• Varying levels of abstraction

• Specification:
• A specific kind of requirements documentation
• Generally more formal, higher level of detail, lower level of abstraction
• Aims to specify the requirements in compliance with the defined specification rules
and guidelines
• Each specified requirement is also a documented requirement
• But not vice-versa

68
 Requirements Documents

69
 Types of Software/System Requirements

• Functional Requirements
• are directly related to the software functionality
• ie: What the system must do
• Frequently expressed as an if/then relationship

• Non-Functional Requirements
• NFRs express constraints that a software must comply with
• Can be seen as specific qualities that a software must have
• “How” the software must do the “What”
• Eg: usability, security

• Requirements-1 (Inverse Requirements)

• IR establish conditions that must never happen
• Frequently associated to an NFR

70
 Requirements Statements
• What types of requirements statements are these?

• System: A Toy Factory Manufacturing Handler

• “The 3D printing subsystem will allow manufacturing to more efficiently produce
peripheral components in order to save money in component sourcing and production
costs.”

• System: Twitter
• “The social media managers should be able to view tweet analytics in order to view
tweet reach and achieve growth.”

• System: Retail Website

• “The webpage must load within 3 seconds.”

• System: Autonomous Vehicle Autopilot

• “The vehicle must be able to detect road obstructions.”

• System: Autonomous Vehicle Autopilot

• “If a road obstruction is detected, the vehicle must apply the brakes within 5
milliseconds.”

71
 Writing Good Requirements
• Good requirements:
• State a need
• Are verifiable
• Are attainable
• Are clear and concise
• Are unambiguous

• Do Not:
• Make assumptions
• Describe processes rather than what must be
attained

72
 Software Requirements Specification (SRS)

• Lower Level of Abstraction and More Formal than Higher-Level Requirements

Documents

• Purpose
• Communication
• Explain the application domain and the system to be developed
• Contractual
• May be legally binding!
• Expresses agreement and commitment
• Baseline for evaluating software
• Supports testing, validation and verification
• “Enough information to verify if a delivered system meets
requirements”
• Baseline for change control

73
 Audience of SRS

• Customers & Users

• Interested in system requirements
• But not detailed software requirements

• System analysts
• Write other specifications that interrelate

• Developers
• Have to implement requirements

• Testers
• Have to check that requirements have been met

• Project Managers
• Have to measure and control the project

74
 Quality Criteria for Requirements Specifications
• Of course need to:
• State a need
• Are verifiable
• Are attainable
• Are clear and concise
• Are unambiguous

• But also:
• Consistent
• Doesn’t contradict itself
• Uses all terms consistently
• Consistent across artifacts
• Ranked
• Indicates relative importance/stability of each requirement
• Modifiable and Readable
• Can be changed without difficulty, unique identification number, etc…
• Traceable
• Origin of each requirement is clear
• Each requirement is labeled for future referencing

75
 Quality Criteria for Requirements Specifications
• Rated
• Relevance and/or stability have been determined and documented

• Up to date
• Reflects the current status of the system and system context, such as current stakeholder wishes or
current legal regulations

• Atomic
• Describes a single, coherent fact
• Does NOT describe multiple isolated or merely loosely coupled facts which can easily be divided into
several requirements

76
 Quality Criteria for Requirements Specifications
• Example:

In order to authenticate himself, the driver enters an electronic card and a PIN. If invalid, the engine does not
start.

R1: The system must respond to event ES-2 in at least 80% of the cases within 2s, and in all cases, within 3s
at the latest for a system load between 80% and 90% of the maximum load as specified by constraint C14
(System load profile).
R2: The normal response time of the system shall be less than 2s.

The user must log on to the system in order to be able to search for a particular order by order ID or by full-text
search in the customer database.

77
 Quality Criteria for Requirements Specifications
• Example:

In order to authenticate himself, the driver enters an electronic card and a PIN. If invalid, the engine does not
start.
Functional, Ambiguous

R1: The system must respond to event ES-2 in at least 80% of the cases within 2s, and in all cases, within 3s
at the latest for a system load between 80% and 90% of the maximum load as specified by constraint C14
(System load profile).
R2: The normal response time of the system shall be less than 2s.
Functional, Non-functional, Unconcise, Ambiguous, R2 cannot be verified. “Normal response time” refers to?
(load, conditions)

The user must log on to the system in order to be able to search for a particular order by order ID or by full-text
search in the customer database.
Functional, Non-atomic (describes user authentication as well as searching for orders)

78
 SRS Should Address:

• Functionality
• What is the system supposed to do?

• External interfaces
• How does the system interact with people, system’s hardware, other
hardware/software?
• What assumptions can be made about these external entities?

• Required performance
• What is the speed, availability, response time, etc. of various functions?

• Quality attributes
• What are the portability, correctness, maintainability, security, and other
considerations?

• Design constraints imposed on implementation

• Are there required standards in effect (impl. language, operating env., etc.)?

79
 SRS Should NOT Address:

• Project development plans

• E.g., costs, staffing, schedules, methods, tools, etc.
• Lifetime of development plans is much shorter

• Product assurance plans

• Configuration management, verification and validation, test plans, etc.

• Designs
• Requirements and designs have different audiences

80
 SRS Can Be Organized By:

• External stimulus or external situation

• E.g., for an aircraft landing system, each different type of landing
situation: wind gusts, no fuel, short runway, etc.

• …System feature
• E.g., for a telephone system: call forwarding, call blocking, conference
call, etc.

• …System response
• E.g., for a payroll system: generate pay cheques, report costs, print tax
info;

• …External object
• E.g., for a library information system, organize by book type

81
 SRS Can Be Organized By:

• …User type
• E.g., for a project support system: manager, technical staff,
administrator, etc.

• …Mode of operation
• E.g., for word processor: page layout mode, outline mode, text editing
mode, etc.

• …Subsystem
• E.g., for spacecraft: command & control, data handling, comms,
instruments, etc.

82