System Development Life Cycle 1 Planning Why build

System Development Life Cycle 1. Planning (Why build the system? ) a. Identifying business value Technique – System request Deliverable – System request

b. Analyze feasibility Technique – Technical feasibility Economic feasibility Organizational feasibility Deliverable–Feasibility study, System concept

Project Management c. Develop work plan Technique – Task identification Time estimation Deliverable – Work plan d. Staff the project Technique – Creating a staffing plan Creating a project charter Deliverable – Staffing plan & Project charter

e. Control and direct project Technique – Refine estimates Track tasks Coordinate project Manage scope Mitigate risk Deliverable– Gantt chart, CASE tool, Standards list, Project binder/s, Risk assessment Project plan

2. Analysis (Who, what, when, where will the system be) a. Analysis Technique - Problem analysis Benchmarking Reengineering Deliverable – Analysis plan b. Information gathering Technique - Interviews Questionnaires Deliverable – Information

c. Process modeling Technique – Data flow diagramming Deliverable – Process model d. Data modeling Technique – Entity relationship modeling Deliverable – Data model, System Proposal

3. Design (How will the system work? ) a. Physical design Technique – Custom development Package development Outsourcing Deliverable – Design plan b. Architecture design Technique – Hardware design Network design Deliverable – Architecture design, infrastructure Design

c. Interface design Technique – Interface structure chart User interface design Deliverable – Interface design d. Database & File design Technique – Selecting data storage format Optimizing data storage Deliverable – Data storage design e. Program design Technique – Program structure chart Program specifications Deliverable – Program design, System specification

4. Implementation (System delivery) a. Construction Technique – Programming, Testing Deliverable – Test plan, programs & documentation b. Installation Technique – Direct conversion Parallel conversion Phased conversion Deliverable – Conversion plan, training plan, support plan

Project Initiation • The first step in any new development project – someone sees an opportunity to improve the business • New systems originate from some business need or opportunity • Many ideas arise from application of new technology • But, understanding of technology is secondary to a sound understanding of the business and its objectives

• Clear understanding of how the system will improve the business • Both IT experts and business experts should work closely – organizations can leverage the exciting technologies • Ultimately, IS needs to organization’s bottom line! affect the • Project Initiation begins with someone, project sponsor, identifies business value in using IT • The proposed project is described very briefly using a technique called the system request

• This is submitted to an approval committee § IS steering committee, or § Senior executives, or § Decision-making body that governs the use of business investments • System request is reviewed, decision is made whether or not, to investigate the proposal • Next step is the feasibility analysis • This decides whether to proceed with the IS development project

• Examines the technical, economic, and organizational pros and cons of developing the system • Provides a slightly more detailed picture of the advantages of investing in the system as well as the possible obstacles • Mostly the project sponsor works with the analyst team • On completion of the feasibility analysis, the system request is revised and submitted along with the final feasibility study, back to the approval committee • The board then decides whether to approve, decline, or table it with additional information

Identifying Business Value: System Request: • Documents the business reasons for building the system and the value it is expected to provide • Typically has four essential components project sponsor, business need, functionality, and expected value

SYSTEM REQUEST [Date] Project Name: [Internet Sales] Project Sponsor: Business Need: Functionality: Expected Value: Tangible: Intangible: Special Issues or Constraints:

Estimating Expected Value/Revenue: • Thumb rules – Internet business might end up generating revenue at least same as that with a half dozen additional stores • Comparing with the best in the business – based on a some percentage of the revenue of the best player in the business, and some annual growth rate to predict future sales • Industry standards – Internet sales is about 20% of the revenues from the traditional stores Estimate conservatively from within the range of figures obtained.

Feasibility Analysis: • Need for the new system and its basic functionality has been defined in the system request • Create a more detailed business case, understand opportunities and limitations associated • Feasibility analysis guides the organization in determining whether to proceed with the project • Three techniques – technical, economic, and organizational • Some firms also conduct a formal legal feasibility to assess conformance with laws

Technical Feasibility: Can we build it? – Technical Risk analysis • Familiarity with application – § Less familiarity generates more risk § Development of new systems is riskier than extensions to an existing system • Familiarity with technology – § Less familiarity generates more risk § Risk increases with new technology itself Contd. .

• Project size – § Large – no. of people in the development team, or time to complete the project, or the no. of distinct features in the system § Large projects have more risk, because § More complicated to manage § Greater chance that some important system requirements will be overlooked, or misunderstood

Economic Feasibility: • Should we build it? – Cost-benefit analysis o Identify Costs and benefits – § Development costs § Development team salary § Consultant fees § Development training § Hardware and Software § Office space and equipment

o Annual operating costs § Software upgrades § Software licensing § Hardware repairs § Hardware upgrades § Operational team salaries § User training o Annual benefits § Cost savings § Increased revenues

• Intangible costs and benefits o Assign Values to costs and Benefits – o Rely on the people who have the best understanding of the costs and benefits o consultants o Past projects o Industry reports

• Determine Cash Flow – o Cost-benefit projections over 4 to 5 years o Assume a rate of growth to adjust for business improvements • Determine Return on Investment – o Consider the time value of money o Calculate the NPV

Organizational Feasibility: How well the system will be accepted by its users and incorporated into the ongoing operations of the organization. • Can be the most difficult feasibility dimension to assess • Conduct a stakeholder analysis

• Project champion(s) § High-level non-IS executive, may/may not be the project sponsor § Promotes/supports the project § Communicates the importance of the project to other organizational decision makers § More than one champion is preferable • Organizational management § Know about the project § Also needs to support the project § Encourage people in the organization to use the system

• System users § Ultimately determine the success/failure of the project by using or not using the system § Important stakeholders § User participation should be promoted throughout the development process • Other stakeholders

Project Management Major activities: • Creating the work plan • Staffing the project • Controlling and directing the project

Creating the work plan: • Dynamic schedule, records and keeps track of all the tasks that need to be accomplished over the life of the project • Lists each task along with the important info about it • The level of detail and the amount of info depends on the needs of the project • Increases as the project progresses

Work Plan Information Example Name of task - Conduct personal interviews Start date - Aug 25, 2006 Completion date - Aug 29, 2006 Person assigned to the task - Sr. Manager; Sunil Malik Deliverable(s) - Top management views Completion status - Open Priority - High Resources needed - Spreadsheet software Estimates time - 12 hours Actual time - 14 hours

Two steps in creating work plan: • Identifying Tasks § Stepwise refinement Top down approach Break high level tasks to subtasks until desired level of detail is achieved § Use a methodology Use a standard list of tasks – template Books, consultants, web sites, past projects

• Time estimation Estimation of time and effort needed to complete the project Assign projected values Estimation software packages – Constar, Construx, Over 50 available in the market Start with a range of possible values, 3 – 4 months Gradually be more specific as the project progresses Try for conservative time estimates

The nos. can come several sources: Experienced developers, consultants Whether it is manual or automated – estimation is a tough job as it involves tradeoffs among three components – size of the system (in terms of what it does), the time taken, and the cost. If time estimate is less than available – two alternatives – reduce functionality or extend deadline.

Two basic ways to estimate time: One – the amount of time spent in the planning phase is used to predict the time required for the entire project. Use industry standard percentages or organization’s own experience. A typical business application spends 15% of its efforts in planning, 20% in analysis, 35% in design, and 30% in implementation phase – in terms of person months.

Two – more complex, more reliable (hoped) is a 3 – step process. • Estimate size of the KLOC/Function Points project in • Estimate Efforts in terms of person-months from the size • Estimate the schedule time in months from the effort. No. of persons required is the total person months divided by the schedule time

Size in KLOC = (Most optimistic + 4*Most likely + Most pessimistic)/6 Size in FP = Total Unadjusted FP * Adjusted Project Complexity TUFP – computed from no. of inputs, outputs, queries, files, and program interfaces PCA – computed from the impact of 14 factors on the complexity like, data communications, rate of transaction, end-user efficiency, complex processing etc.

FP can be converted to LOC depending on the language of implementation. C– 130 lines/FP COBOL – 110 lines/FP VB – 30 lines/FP Java – 55 lines/FP Effort (in person months) = 1. 4 *Thousands of LOC (A thumb rule for small/moderate sized business software) Schedule time (months) = 3. 0 * personmonths 1/3 Historical data or estimation software can be used

Timeboxing: • Task-oriented projects vs. time-oriented projects • Used in Rapid Application Development (RAD) methodologies • Sets a fixed deadline for a project • Delivers the system by that deadline no matter what, even if functionality needs to be reduced

• Ensures that project teams do not get hung up on the final “finishing touches” that can drag out indefinitely • Satisfies the business by providing a product within a relatively fast time frame • Deadline should not be impossible to meet • Build the core of the system to be delivered • Timeboxing creates a sense of urgency, helps focus on the most important features • Functionality that cannot be completed needs to be postponed

• Prioritized set of functionalities are implemented • However, quality cannot be compromised, regardless of other constraints, e. g. , do not reduce testing time without reducing features • A high quality system is delivered at the end • Future iterations will be needed to make changes and enhancements • Timeboxing approach may be used once again!

Staffing the project: • Means much more than assigning people to the project § Matching people’s skills with the needs of the project § Motivating them to meet the project’s objectives, and § Minimizing the conflict that will occur over time • Deliverable – staffing plan delineating § The people along reporting structure with the § The project charter, describing the project’s objectives and rules overall

• After the estimates are complete, a staffing plan is created § Lists the roles required for the project § The proposed reporting structure § Project manager oversees the overall progress of the project § A functional lead is be assigned to manage a group of analysts § A technical lead oversees the progress of a group of programmers and technical staff members

§ There are many team structures, popular one is chief programmer team structure § Next, assignment of persons is done, one person may fill more than one role on a project team § While making assignments, think in terms of ‘technical skills’ and ‘interpersonal skills’ § Interpersonal skills – customers, senior management, and team members § Training/mentoring may be required for both

• Motivation: § Recognition is a good motivator § Motivation has a great influence on performance § Do/Don’ts • Assign unrealistic deadlines • Ignore good appreciation efforts - show • Make decisions without team’s inputs • Do maintain good working conditions/ environment – working space, lighting, technology, privacy

• Handling conflict: § Organize the project to minimize conflict among group members § Group cohesiveness contributes more to productivity than individual capacities § Define roles clearly § Hold team members accountable for their tasks § Develop a detailed project charter listing the project’s norms and ground rules

§ When the team should be at work § When staff meetings will be held § How group members will communicate with each other § Procedure for updating the work plan as tasks get completed

Staffing Plan: Role Description Assigned To Project Mgr. -oversees the project, Moon. Swamy to ensure that it meets the time and cost req. Infrastructure - ensures the system Sobhraj Analyst conforms to infrastructure standards System analyst -designs the IS-focus on Bani interfaces with distribution system

System analyst - designs the IS-focus on the process models & interface design Bala System analyst - designs the IS-focus on Raju data models & system performance Programmer coding Joy Programmer coding Toy

Project Charter: Project objective: The project team will create a working Web-based system to sell CDs to customers. The Internet sales system team members will • Attend a staff meeting each Friday at 2. 00 pm to report on the status of assigned tasks. • Update the work plan with actual data each Friday at 5. 00 pm.

• Discuss all the problems with Moonswamy as soon as they are detected. • Agree to support each other when help is needed, especially for tasks that could hold back the progress of the project. • Post important changes to the project on the team bulletin board as they are made

Controlling and directing the project: • Final step of project management • Continues until the final product is delivered to the project sponsor and the users • Includes – refining original project estimates, tracking tasks, encouraging efficient development practices, managing scope, and mitigating risk • These activities ensure that the project stays on track, and chances of failure is kept at a minimum

• Refining estimates: § Follows a cyclone/hurricane model § Better predictions are made after tracking the cyclones for some time § Accurate predictions as they approach a coast § According to one leading expert Barry W. Boehm § A well-done project plan has a 100% margin of error for project cost, and § A 25% margin of error for schedule time

Margins of error for well-done estimates: Phase Deliverable Cost(%) Time(%) Planning System request 400 60 Project plan 100 25 Analysis System proposal 50 15 Design System specification 25 10

Possible actions when a schedule date is missed: • If you assume rest of the project is simpler than the part that was late, and is also simpler than believed when the original estimates were made, do not change schedule – high risk • If you assume rest of the project is simpler than the part that was late, and is no more complex than the original estimate, increase the total schedule by the amount of time you are behind – moderate risk • If you assume that the rest of the project is as complex as the part that was late, then increase the entire schedule by the percentage of weeks that you are behind – low risk

Tracking tasks: • Work plans are updated with actual numbers regularly • Shared with every team member • Better tracking helps in better staffing decisions, predicting deadlines, calculate costs accurately, and understanding of the progress of the project • Scrutinize the work plan regularly for potential issues – delays, resources • Tasks may be interrelated, or may overlap • Develop the work plan graphically – Gantt chart • Tasks and time are plotted along y- and x-axes • Shading indicated completion of tasks

Coordinating Project Activities: Three techniques are commonly used to help coordinate. • CASE tools: § Automates all or part of the development process § Upper CASE tools – used in analysis and design phase § Lower CASE – used in generating code § Integrated CASE – contains functionality of both § Visible Analyst Workbench, Oracle Designer, Rational Rose, Logic Works suite

• Standards: § With many people things can get messy and confusing § Create standards that the project team must follow § Task coordination becomes simple § Standards work best if created at the beginning of each major phase of the project, and communicated well § Some standards are applied for the entire SDLC e. g. , file naming conventions, status reporting, documentation, procedural standards etc. § Others will be applied as appropriate e. g. , coding standards and guidelines, User interface design standards etc.

• Documentation: § A final technique applied is good documentation § Includes detailed info about the tasks of the SDLC § The documentation is stored in project binder(s) § Binders contain all the deliverables and all the internal communication that takes place – the history of the project § Never wait till the last minute to create documentation § Document the system’s history as it evolves § Include dividers to separate content according to major phases, internal communication § Takes time up front, but pays off in the long run

Managing Scope: • Follow the steps for good project management – stay on schedule, no schedule or cost overruns • Scope creep – occurs when new requirements are added to the project after the original scope was defined and “frozen”! • Many reasons § Users suddenly understand the potential of the new system and realize new, useful functionality/ies § Developers discover interesting capabilities, to which they become attached § A Sr. Mgr. may wish to let the new system support a new strategy developed at a recent board meeting

• Addressing changes is increasingly difficult after the project begins - focus is removed from original goals • Impact on cost and schedule • Project manager’s role is critical to keep scope creep to a minimum • The key is to identify the requirements as completely as possible early • Use of prototyping and presentations/meetings – reduces scope creep to less than 5%

• Allow only requirements absolutely necessary • Assess the ramifications – project team members, deadline may be offset • Track the implementation of change so that an audit trail exists to measure the change’s impact • Sometimes, additions are recorded as future enhancements

Managing Risk: • Final facet of project management • Assessment of risk and addressing the risks • Many causes – weak personnel, scope creep, poor design, too optimistic estimates • Risk assessment document tracks potential risks § Likelihood of risk § Potential impact § Addressing the risk

• Assess the root cause/s • Prioritize risks • List of risk changes – as some are removed others surface • Good project managers work hard to keep risks from having an impact on the schedule and costs