Software Development Process Guidelines for Project Managers

1. Software Development ProcessGuidelines for Project Managers Dr. Moshe Gotesman, PMP <>

2. Organization • Software Engineering • Techniques • Processes • Software Product Life Cycle • Software Development Life Cycle (SDLC)

3. Software engineering • Software Engineering deals with the software product as an engineering effort. • Software engineering has two main components: • Techniques • Processes

4. Software Engineering Techniques • Programming languages • Programming paradigm • Databases • Graphical user interfaces • Programming tools • Libraries • Design languages • Patterns • Processes and methodologies • Platforms • Other Practices • Other tools

5. Software Engineering Processes • In order to develop software products as an engineering feat, there must be processes • High level processes define the Software Product Life Cycle (SDLC)

6. Software Product Life Cycle • There are many different SDLC strategies but they all roughly cover the same basic activities: • Marketing Requirements Document • Product development approval • Project planning • Requirements Analysis  • Functional Specification  • Design and Architecture  • Coding  • Testing  • Documentation  • Training • Release/Integration • Maintenance

7. Software Development Process • The software development process cover those parts of the SDLC that actually develop the product. • MRS • Product development approval • Project planning • Requirements Analysis  • Functional Specification  • Design and Architecture  • Coding  • Testing  • Documentation  • Training • Release/Integration • Maintenance

8. Software Product Life Cycle • SDLC models defer in how that arrange and combine the various activities. • Most SDLC models fall into the following main types: • Predictive • Adaptive

9. Predictive Life Cycle Models • The waterfall model has well-defined, linear stages of systems development and support • The spiral model shows that software is developed using an iterative or spiral approach rather than a linear approach • The incremental release model provides for progressive development of operational software • The prototyping model is used for developing prototypes to clarify user requirements • The RAD model is used to produce systems quickly without sacrificing quality

10. Adaptive Life Cycle Models • Extreme Programming (XP): Developers program in pairs and must write the tests for their own code. XP teams include developers, managers, and users • Scrum: Repetitions of iterative development are referred to as sprints, which normally last thirty days. Teams often meet every day for a short meeting, called a scrum, to decide what to accomplish that day. Works best for object-oriented technology projects and requires strong leadership to coordinate the work

11. Software Life Cycle Models • Linear Sequential Model (waterfall) • Iterative development (RUP) • Incremental Model • Agile Programming • Many others (not popular)

12. Linear Sequential Model Classic Life Cycle Model or Waterfall Model Advantages -- documentation -- easy to maintain Disadvantages -- rarely followed in real projects -- often difficult for the customer to state all requirements explicitly -- must with patience in customers -- leading to “block states”

13. Iterative Development - RUP Model Iterative Life Cycle Model Advantages -- Flexible Disadvantages -- Complex

14. Core Product Incremental Model Combining the elements of linear sequential model with iterative prototyping

15. Incremental Model Advantages -- delivering an operational product with each increment -- useful when staffing is unavailable for a complement implementation -- with better plans to manage technical tasks Disadvantages -- build-and-fix danger -- invalid when the project deadline is tight or when the customers cannot accept the phased deliverables

16. Activity Specific Processes • Each of the activities/phases in the SDLC model is controlled by its own specific processes. • Project Manager must be knowledgeable and familiar with these practices and processes.

17. Documentation • Regardless of the lifecycle model, it is important to produce some documentation during the software development period • (note: Agile development models prefer communication over documentation but I disagree. Long term, documentation is unavoidable). • The important issue here is not “do we need documentation?” but “What and how much documentation do we need?” • No documentation is a call for trouble.

18. Documentation • That does not mean documentation has to be heavy. • Even light-weight documentation can go a long way.

19. Documentation • If you work in an environment which does not have a “documentation culture”: • Insist on establishing the culture • Start with something • Incomplete is better than nothing • Must be official but does not have to be formal • It’s OK to move to the next step before the doc is perfect. • Update regularly (as necessary) • Make sure there is a (simple) process to: • Make changes • Review and approve • Freeze • Control Version/Revision

20. Documentation • Each document should have • A sponsor • One and only one owner • Contributors (optional) • Reviewers • Mandatory (approvers) • Optional

21. Documentation • Sponsor – executive level responsibility/authority • Owner – execution responsibility and liability • Contributors – help the owner by providing some of the material

22. Documentation • Mandatory reviewers • Must review the document • Document cannot be approved without • Are given a due date for completing the review • Not responding by the due date implies no comments (= agree with all the content) • Let then know about these rules (process)

23. Documentation • Optional reviewers • Are not a condition for signing-off • Are “nice to have” • Document owners is not required to accept their comments • Have the same due date as the mandatory reviewers but it’s only suggested.

24. Documentation • Approvers • Usually the mandatory reviewers. • Obtain formal approval in the form of sign-off • Signature on hard copy • Email approval • Electronic signature

25. Documentation • An approved (signed-off) document is • Frozen !! • Committing • Any changes must go through a new update-review-approve cycle

26. The Software Documentation Chain • A typical documentation set will include: • Requirements Specification • Functional Specification • Architecture/design • Detailed design • Test Plan • Test Specification • Test Reports

27. The Requirements Specification • The Requirements Specification is the most important document in the software development documentation. • If nothing else, insist on a Requirements Specification. • The Requirements Specification is the beginning of everything. • Who uses the Requirements Specification?

28. The Requirements Specification • Who uses the Requirements Specification? • Customer • Product manager • Engineers • Testing

29. The Requirements Specification • The Requirements Specification must be approved by the customer and usually becomes a part of the contract.

30. The Requirements Specification • The Requirements Specification describes the “feature set” of the product • From the (non-technical) customer and end-user perspective • If the (non-technical) customer and/or end-user can experience it, it has to be in the Requirements Specification

31. The Requirements Specification • Do not include items that the (non-technical) customer and/or end-user cannot experience, unless they explicitly require them. • Performance • Quality/stability • Interoperability • …

32. The Requirements Specification • Don’t confuse with design! • Say what it does, not how it does it • No tech lingo and details (unless explicitly required by the customer) • File system • DB • Programming language • Communications protocols

33. The Requirements Specification • Requirements should be short, clear, individual, testable • Use a numbering system! Very easy and very useful

34. The Functional Specification • If you don’t have a Requirements Specification, how will you be able to have a Functional Specification? • The Functional Specification • Describes how each Requirement should be implemented. • Is a high level guideline to the SW architects/implementers on how to write the code • Yes, it’s technical  • Internal document. Not to share with customer

35. The Functional Specification • Use a numbering system • Reference each entry back to the corresponding entry in the Requirements Specification • A single requirement can generate multiple entries in the Functional Specification.

36. The Architecture/Design Document • If you don’t have a Functional Specification, how will you be able to have a Architecture/Design? • The Architecture/Design Describes the high level items of the SW: • Main components/modules • Interfaces • Communications protocols • Internal document. Not to share with customer

37. The Architecture/Design Document • Common designs: • Client-server • Distributed computing • Peer-to-peer • Blackboard • Implicit invocation • Monolithic system • Three-tier model • Service-oriented architecture

38. The Architecture/Design Document • Reference each entry back to the corresponding entry in the Requirements Specification and/or Functional Specification.

39. The Detailed Design Document • Full details of each component, module, API, interface, data structure, algorithm • Down to the level of function signature

40. Test Plan • Describes everything about the testing except the individual tests themselves. • Testing procedure • Requirements traceability • Tested items • Testing schedule • Test recording procedure • HW/SW requirements • Test types (unit, integration, release, etc.) • Release criteria

41. Test Specification • The recipe book of all the tests • Step-by-step instructions for each test • Test # %%% • Start by doing this • Then do this • Then do this • …

42. Test Report • Details the results of a testing activity • What was done • How did it go • What were the results

43. Software Configuration Management • Software Configuration Management handles the changes of software artifacts over time. • Code • Documents

44. Version Numbers • We need to track the versions of • Code • Documents