SDLC

SYSTEM DEVELOPMENT

CLASS OBJECTIVES

To understand and identify the challenges of modern information systems acquisition and management To acquire skills and strategies for becoming effective and efficient in all phases of planning, and managing application development To directly experience the methods and practice of systems analysis and design from the MIS perspective 2

REVIEW: ASSIGNMENT #1 AND THIS CLASS

3

WHAT SAD TOPICS ARE A PRIORITY? We only have 1-semester to study SAD! Too many topics, so must prioritize and focus on the key areas. How shall we determine this? Ans: We will interview MIS professionals to help us determine priorities, needed skills, and important tools/techniques

4

ASSIGNMENT #1: SAD AND MIS Task is to interview an “MIS professional” about SAD topics. “What should a successful MIS person know?”  http://itmvm.shidler.hawaii.edu/itm353/asst1.htm  Reports will be aggregated to develop a set of topics we will focus on this semester!  ** NOT MUCH TIME TO COMPLETE THIS ** 



Have you signed up an MIS professional ? 5

EXERCISE: PLANNING A WEDDING 

3 months from now; 200 guests (20% from out of state); $15,000 budget     

What do you need to do? Who does what? How do you get started? What are the tradeoffs? How confident are you that you can succeed?

CHAPTER 1

Project Team Roles and Skills

7

THE TAR PIT Developing large software systems is "sticky"  Projects usually emerge from the tar pit with running systems, but most missed goals, schedules, and budgets  "No one thing seems to cause the difficulty – any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion"  Analogy meant to convey that it is hard to discern the nature of the problem(s) facing software development 

8

WHY ARE SOFTWARE PROJECTS LATE? Estimating techniques are poorly developed Our techniques confuse effort with progress Since we are uncertain of our estimates, we don't stick to them Progress is poorly monitored When slippage is recognized, we add people ("like adding gasoline to a fire")

9

OPTIMISM "All programmers are optimists" "All will go well" with the project – thus we don't plan for slippage However, with the sequential nature of our tasks, the chance is small that all will go well

10

THE MYTHICAL MAN-MONTH Cost does indeed vary as the product of the number of people and the number of months Progress does not!!

11

MMM - 2 

The unit of man-month implies that people and months are interchangeable This is only true when a task can be partitioned among many workers with no communication among them  When a task is sequential, more effort has no effect on the schedule – many tasks in software engineering have sequential constraints 

12

MMM - 3 Most tasks require communication among workers Communication consists of Training Sharing information (intercommunication)

Training affects effort at worst linearly Intercommunication adds n(n-1)/2 to effort – if each worker must communicate with every other worker

13

DEVELOPMENT TEAM How should the development team be arranged? The problem: good programmers are much better than poor programmers Typically 10 times better in productivity Typically 5 times better in terms of program elegance

14

THE DILEMMA OF TEAM SIZE Consider a 200-person project with 25 experienced managers The previous slide argues for firing the 175 workers and use the 25 managers as the team

15

THE DILBERT VIEW

TWO NEEDS TO BE RECONCILED For efficiency and conceptual integrity a small team is preferred To tackle large systems considerable resources are needed Some solutions: Harlan Mill's Surgical Team approach – one person performs the work, all others perform support tasks Pair programming 17

THE PROPOSED SURGICAL TEAM Surgeon – chief programmer  Co-pilot – like surgeon but less experienced  Administrator – relieves surgeon of administrative tasks  Editor – proof-reads documentation 

2 Secretaries – support administrator and editor  Program clerk – tracks versions  Toolsmith – supports work of the Surgeon  Tester  Language lawyer 

18

HOW IS THIS DIFFERENT? Normally, work is divided equally – now only the surgeon and copilot divide the programming work  Normally each person has equal say – now surgeon is the absolute authority  Note communication paths are reduced 

Normally 10 people -> 45 paths  Surgical Team -> at most 13 paths 

19

HOW DOES THIS SCALE? Reconsider the 200 person team – communication paths -> 19,900! Create 20 ten-person surgical teams Now only 20 surgeons must work together – 20 people -> 190 paths, two orders of magnitude less Key problem is ensuring conceptual integrity of the design (integration issues)

20

WHY DID THE TOWER OF BABEL FAIL? Communication (the lack of it) made it impossible to coordinate How do you communicate in large project teams? – informal (telephone, email), meetings, workbook 21

WHY DID THE TOWER OF BABEL FAIL? - 2 

Workbook Structure placed on project's documentation  Technical prose lives a long time, best to get it structured formally from the beginning, also helps with distribution of information 

22

WHY DID THE TOWER OF BABEL FAIL? - 3. 

Team Dynamics Teams can (and sometimes do) fail  You will need to do some actual work to make your team successful! 



Let’s learn about the “One Bad Apple” syndrome

23

PROGRAMMING PROJECT EXAMPLE ROLES 

A project leader 



An architect 



provides the fundamental design for the program, ensures that design is implemented, finds alternatives when things don't work or time is a problem

A requirements satisfaction lead 



schedules meetings, keeps track of progress, tracks and reports risks, assigns specific tasks and makes sure they get done (or finds alternatives), is the communication hub for the team

clarifies project requirements, ensures that requirements are met by providing test cases, inspections, checklists, etc.

A test lead 

performs tests, analyses results, reports on tests

24

PROGRAMMING PROJECT EXAMPLE ROLES -2 

A lead programmer 



breaks apart programming tasks into parts that can be naturally integrated later, estimates programming effort for parts, works with project leader to assign programming tasks, performs critical-path programming tasks, ensures that parts meet quality and functionality expectations

A quality lead 

ensures that the program and related materials meet quality expectations, reports on quality issues, performs quality improvement (i.e. clean-up) as needed, in particular, is responsible for ensuring code has adequate documentation, sets and ensures that user interface meets usability expectations, establishes acceptable level of defect (e.g. "bugs") tolerance, presents plans for improving quality and enforcement of plan

25

PROJECT TEAM SKILLS AND ROLES Projects should consist of a variety of skilled individuals in order for a system to be successful.  Six major skill sets an analyst should have include: 

     

Technical Business Analytical Interpersonal Management Ethical 26

INTRO TO THE SDLC

A “Simple” Process for Making Lunch

Slide 28

IS A SDLC REALLY NECESSARY? You have 5 mins to write instructions on how to make a peanut butter and jelly sandwich GO!!!

IS A DEVELOPMENT PROCESS REALLY NECESSARY? 

How can you help ensure…          

you will make the correct thing? you will make the thing correctly? you did not leave out something important? you did not add something unnecessary? you will stay on budget (e.g. time)? you make efficient/effective use of your time? you can plan your effort realistically? you do not get derailed by problems? you are getting the best possible outcome? you enable changes and updates later?

THE PROJECT AND ITS LIFECYCLE 

The project Moves systematically through phases where each phase has a standard set of outputs (deliverables)  Each deliverable is an input to the next phase  Through a process of gradual refinement this results in actual information system 

PROJECT PHASES 

Planning (or Initiation) 



Analysis 



How will the system work?

Implementation 



Who, what, when, where will the system be?

Design 



Why build the system?

System delivery

Maintenance/evolution

PLANNING Identifying business value  Analyze feasibility  Develop work plan  Staff the project  Control and direct project 

ANALYSIS Information gathering  Process modeling  Data modeling 

DESIGN Physical design  Architectural design  User Interface design  Database and file design  Program design 

IMPLEMENTATION Construction  Installation  Transition 

PROCESSES AND DELIVERABLES Process

Product

Planning

Project Plan

Analysis

System Proposal

Design Implementation

Slide 37

System Specification New System and Maintenance Plan

SDLC METHODOLOGIES 



A development process implements the SDLC There are many development processes    

 

Risk is the main determiner as to what process to use (or to use one at all) There are only two basic approaches  



Waterfall Spiral Agile methods RAD

Structured (or “data flow” oriented) OOAD

Each approach has it benefits and liabilities Context of the problem decides (for most modern systems OOAD is best)  However it is often useful to mix approaches 

OBJECT-ORIENTED ANALYSIS AND DESIGN Attempts to balance emphasis on data and process Often uses Unified Modeling Language (UML) for diagramming Use-case Driven Architecture Centric Iterative and Incremental

Example methodology: RUP

Slide 39

AGILE APPROACH http://agilemanifesto.org/

SELECTING A DEVELOPMENT METHODOLOGY http://software-quality.blogspot.com/2006/10/riskbased-selection-for-agile.html  http://www.construx.com/File.ashx?cid=817  Mostly based on risk considerations 