Download Organization, System Specification-Software Project Management-Lecture Notes and more Study notes Software Project Management in PDF only on Docsity!
LECTURE # 26
5. ORGANIZATION
4.8.1 Life cycle Models
To ensure the successful execution of a project, it is necessary to break down the project into: multiple manageable tasks.
Each task is performed in a series using processes. To understand what a process is, consider an example of a non software-related project. You are planning the market launch of an office management product. To create an effective plan, you need to perform certain tasks.
- First, you schedule a meeting of all managers and the Finance, Marketing, Production, and Systems personnel. You can follow a process to complete this 'task. You may send email messages or call them up personally.
- Next, you decide some feasible marketing and advertising strategies. Again there are processes that help you select the strategies.
- Fina1ly, you determine the territory where the product should be launched. This is done in consultation with the Production and Marketing departments.
Just like a non software-related project plan consists of multiple processes, a software development activity also consists of multiple tasks. A process or a combination of multiple processes is required to complete each task. A typical SDLC follows a consistent sequence of processes or a process model.
A process is defined as a collection of related tasks with specific milestones. To ensure smooth progress of a software project, relevant processes are arranged and executed in a sequence. Every software project is discrete with respect to its complexity, size, and goals. Therefore, different process models are designed for different software projects. These process models provide approaches that decide the path of software development from the conceptualization of a project to its formal termination.
- The Waterfall model : This is the traditional life cycle model. It assumes that all phases in a software project are carried out sequentially and that each phase is completed before the next is taken up.
- The Prototyping Model : A model that works on an iterative cycle of gathering customer requirements, producing a prototype based on the requirement specifications, and getting the prototype validated by the
docsity.com
customer. Each iteration of the life cycle builds on the prototype produced in the previous iteration.
- The Incremental Model : The Incremental model is an example of an evolutionary life cycle model. It combines the linear nature of the Waterfall model and the iterative nature of the Prototyping model. The Incremental model divided the development life cycle into multiple linear sequences, each of which produces an increment of the final software product. In this model, the software product is developed in builds. A build is defined as a self- contained unit of the development activity. The entire development cycle is planned for a specific number of logical builds, each having a specific set of features.
- The Spiral model : Another evolutionary life cycle model that combines the linear nature of the Waterfall model and the iterative nature of the Prototyping model. The project life cycle is divided into phases, and each phase is executed in all of the iteration of the Spiral Model.
- The RAD Model :
A Process defines the overall processes that an organization needs to follow to manage a project efficiently. It defines a structured approach to sequence the phases and identify the requirements of each phase in the SDLC. The definition of the phases in a process model helps organize, monitor, and execute a project efficiently.
A process model is flexible and does not follow any rigid rules of implementation. An organization can deploy a totally new process model for its overall software development effort. It can also customize an existing process model to merge with its implemented process model. For example, figure 1, shows two process models, A and B. Process model A was used by an organization that manufactures confidential defense applications. The management used the model to plan extensively for unexpected project risks. However, after discussing with the project managers and system analysts, the organization wants to merge its current process model with a model lat has simple and consistent SDLC phases. This leads to the evolution of the process model B.
docsity.com
allocated time and ensure maintenance of quality and measurability throughout the project.
With so many process models available, a project manager is likely to face the dilemma of selecting the right process model for managing a software project efficiently.
To select a process model that is suitable to a project, the following criteria can be considered:
Business goals of the organization Expected size of the project Client and project requirements Availability of funds and development staff Risks perceived in the project
Business Goals of the Organization This criterion indicates the overall approach and mindset of an organization. If the organization has a past history of developiI;1g projects in accordance with well-defined plans and other job aids in every phase, the suitable process model can be the Waterfall model. However, if the organization is well equipped with the resources to deal with financial, technological, and personnel risks, it can choose the Spiral model. The organization can choose the Prototyping model if it is used to working in an experimental and a constant feedback mode.
Expected Size of the Project If the size of a project is extensive and the client prefers all the features of the proposed project at the first delivery, you can select the Waterfall model. When you want the entire product to be developed and delivered in piecemeal so that the clieI;1t can immediately begin the unit testing of each module, you would select the Incremental model. In contrast, if the size of the project is doubtful, you can go for the Prototyping or Spiral model. These models help to develop projects that have a vague and uncertain estimate of the project size.
Client and Project Requirements The Waterfall model or the Incremental model is chosen if the client needs and the project requirements are defined and approved. In addition, no changes or negligible changes are 1 expected in the future regarding design requirements. In contrast, you would choose the Spiral j and Prototyping models when the client needs and system requirements are uncertain and is likely to change in the future.
Availability of Funds and Development Staff The Waterfall and Prototyping models require predetermined and adequate resources at the start of a project. However, if you expect additional funds and human resources as you progress through the different phases, you should go in for the Incremental or Spiral models. This is because the Incremental model operates on the assumption of developing a project into several builds due to lack of human resources. Similarly, the funds and
docsity.com
staffing requirements in the Spiral model may increase or decrease depending on the changes in requirements arid feasibility of the proposed project in the future. Risks Perceived in a Project This is yet another important criterion for the selection of a process model. You choose the Waterfall or Incremental model if the occurrence of risks and their impact perceived is minimum. However, you should go in for the Spiral model if the risks and their perceived impact are very high.
You should use the waterfall model if:
The project is large yet it is clearly divided into discrete phases and each phase has defined number of days, personnel, and resources allocated. The Waterfall model requires the presence of defined phases and processes in each phase.
The development also perceives that it can have defined set of input and certified output. This is because each phase would lead to another and the next phase would not begin until the previous phase is certified as closed. This way baselines and milestones for each phase can be identified. The Waterfall model assumes the closure of a previous phase before the successive phase begins. This ensures linear progression of a project where developers do not need to revert to an earlier phase or a process.
The development team is not likely to face any bumps in the development process because of clear cut project requirements as well documentation provided to them by the client. Clarity of project vision and project requirements are the essential features of the Waterfall model, which are fulfilled in the preceding scenario.
Therefore, if the requirements are defined and a project is large enough to be divided into defined phases, you can go for the Waterfall model.
However Waterfall model has the following drawbacks:
- There cannot be a sudden crossover from one phase to the next. Real-time projects require sudden crossover between phases because such projects are subjected to change in every phase of the development cycle. For example, real-time projects such as embedded software development where the phases and the requirements for every phase cannot be determined at the analysis phase cannot deploy the Waterfall model.
- Another reason for the unpopularity of the Waterfall model is that it requires too much effort for stringent documentation-in every phase. Every phase is closed with formal documentation. Projects with predictable final product, such as banking software or an airline reservation project, usually have formal documentation. This is because the phases of these projects are defined. However, it is difficult for research and development (R&D) related projects to complete all project documentation.
- The Waterfall model does not support the development of a working model of a
docsity.com
- When there is a conflict in client requirements.
To resolve the conflict, the development team develops a working model so that the requirements of the client become defined. Defined client requirements enable the physical development of the actual product.
The Prototyping model enables an analysis team to first construct a working model with their prior software experience combined with the vague needs of the client.
The Prototyping model can be as simple as a drawing on a paper or as complex as the real working software. The closer your prototype is to the actual product, the more precise is your evaluation.
There are different types of prototyping methods that an organization can implement:
Rapid prototyping Reusable prototyping Modular prototyping
Rapid prototyping This model is suitable when:
- The cost and time required to create a prototype is minimal. - The project has a substantially long cycle - Development team wants the design to be strong.
Reusable prototyping This model is used when:
- The old design needs major changes but the supplementary components of the old design do not need major changes.
Modular prototyping This model is used when:
- Considerable cost, time and effort are deployed to create a prototype. - Client feedback for enhancements is not major - Minor improvisations are needed to obtain client approval.
Using the Prototyping model saves cost and time involved in the build-it-twice approach. The experience of developing the prototype is useful for developers while developing the final product. It reduces the risks of an unfeasible project design because the developers gain a fair idea of the resources and the probable time taken to create the [mal product. They also get a feel of the implementation tool to be used in the project.
Incremental Model
docsity.com
You can use the Incremental model approach in software projects:
- Where human resource is scarce.
In such cases, the management can decide to divide and develop a product in individual builds. When the resources are available, the subsequent builds are planned and executed. This process model is useful in real life because normally all the resources required to complete the project are not available at the same time.
Example :
Consider a situation in which you might need to use the Incremental model of SDLC. Supersoft2000 requires a software product that automates the employee and their salary details. It has assigned this project to Blue Valley Consulting (BVC) that specializes in developing Human Resources (HR)-related applications. The project requirements are defined to start the project. However, the client wants to roll out the new system for the benefit of its employees as early as possible. The analysis team in BVC has been able to divide the entire project into seven independent modules. On the basis of their prior experience, it feels each module can be executed and deployed independently by the client. After all the modules are completed, the maintenance team in BVC can assemble and implement the system at the client site. Currently, the development personnel in BVC are hired on contract and BVC faces shortage of skilled personnel.
In such a case, you use the Incremental model because of the following reasons:
- Time and lack of skilled personnel are the main hindrances in this project.
Therefore, by using the Incremental model, you can design, develop, and deliver independent modules. This way by using a few skilled personnel you are able to develop a system with basic features and provide it to the client immediately. The most important and the least dependent module are developed first. While the client is using the module, BVC can arrange for additional skilled personnel to complete the rest of the modules and deliver them to the client.
The Incremental model enables you to revert to an earlier phase and refine the product based on client feedback. After all the modules have been developed, the development personnel can be released. BVC can then hire or retain a few experienced personnel to create a maintenance team. This team would assemble and implement the entire employee salary details product at the client site. This flexibility of personnel can be exercised because you use the Incremental model. Using the Incremental model enables:
Division of skilled labor Division of a complex project into modules Development of those modules within a short time frame
docsity.com
1. The Project Development Plan The Software Test Plan
The requirements phase formally concludes with the project's first major review: the software requirements review (SRR). It is this review that signs off the requirements specification and formally declares the requirements document as the first approved project baseline.
2. The Statement of Requirement (SOR)
The project manager (or the advising consultant adopting this role) must ensure that the project sponsor has produced a written statement of requirements (SOR). This must be a thorough document which is:
o Unambiguous o Fully defined or complete o Verifiable deliverables o No conflicts o Consistent o Auditable
The SOR will be the document against which change control will be exercised. The SOR should be closely matched to the contract and there should be no conflict of interests between the two. Where consultants are involved, the client or sponsor SOR will normally form the basis of the proposal. All of these documents must carefully align and there should be no scope for misinterpretation, confusion or lack of understanding. This will be the cornerstone of the project.
3. System Specification
If a System Specification has been properly developed, nearly all information required for a description of software scope is available and documented before software project planning begins. In cases where a specification has not been developed, the planner must take on the role of system analyst to determine attributes and bounds that will influence estimation tasks.
4. Design Specification
The first stage of risk analysis requires a review of all, project technical and administrative plans in order to identity potential problems. It includes:
The project development plan The requirements specification The design specification
docsity.com
All major dependencies in the project development plan are examined and evaluated.
Examples may be the dependence on external sources such as subcontractors, vendors and suppliers, and service providers. Problems will arise if external components or services are not provided on time, or if they do not function as expected.
The project design specification is a detailed plan of how the requirements are to be implemented.
The implementation decisions involved may contain potential problems, For example, problems will arise if the selected hardware turns out to be inadequate, such as if the CPU is too slow, the LAN is not sufficiently reliable, or the maximum available memory is insufficient.
A list of all anticipated problems is then compiled, identifying each problem and describing the potential effect on the project. Following table presents an example of an anticipated problem list.
Table 1: Example of an anticipated problem list
Problem Description
- Late delivery of the If the computer is not delivered by June 1, as Development computer planned the integration phase will be delayed.
- Insufficient memory The size of the memory resident part of the System may exceed 8 megabytes (the maximum memory size supported by the computer).
- No operating system The system requires changes to the standard expert operating system. John Adams is the only OS Expert in the company, and he may not be available for this project.
- System response time The required system response time to the input too slow. may exceed the 5 seconds specified in the requirements.
- High staff turnover The schedule is tight with only minimal slack time. If there is more than average staff Replacement during development, we will slip the schedule.
docsity.com
in the required development stages and reviews, requiring system design to be followed by software requirements, software design, implementation and testing.
The Data Item Descriptions define the formal documentation standards for all required documents generated during the development of software according to standard 2167. DID s apply to the development of one or more computer system configuration items (CSCI s), a term used throughout the 2167 standard to identify high level decomposition components of a computer system. Table 2: DOD Data Item Descriptions (DID s)
Development documentation Software development plan
System documentation System/segment specification System/segment design document
Software design and requirements Software requirements specification Software design document
Interface design and requirements Interface requirements, specification Interface design document
Version description Version description document
Test documentation Software test plan Software test description Test report
Release manuals Computer system operator's manual Software user's manual Software programmer's manual Firmware support manual
Maintenance documentation and source code Computer resources integrated support document Software product specification
docsity.com
A CSCI, as applied to software; is a component of the system that can be individually controlled, configured, tested and documented. CSCI s are often reviewed and approved as separate development items, and though a single review or audit can consider more than one CSCI, each is usually addressed separately during the review process. There are no clear-cut guidelines for the division of a software system into CSCI s as the division is essentially one of convenience.
Table 3: DOD Data Item Description standards
Data requirements title Acronym
- System segment design document SSDD 2.Software development plan SDP 3.Software requirements specification SRS
- Interface requirements specification IRS
- Interface design document IDD
- Software design document SDD
- Software product specification SPS
- Version description document VDD
- Software test plan STP
- Software test description STD II. Software test report STR
- Computer system operator's manual CSOM
- Software user's manual SUM
- Software programmer's manual SPM
- Software support manual FSM
- Computer resources integrated support document CRISD
- Engineering change proposal ECP
- Specification change notice SCN
Table 3 contains a list of the DID s referenced by standard 2167A. The software quality DID is referenced separately in the DOD software quality program standard 2168. All DID document formats follow a similar pattern. Several of the sections are common to most, if not all of the documents, such as:
Title page format Table of contents Scope (including identification, overview, references etc.) Other applicable documents Notes and appendices
docsity.com
testing activities quality assurance activities configuration control activities other required development activities
- Identify the requirements that are not applicable, justifiable or reasonable for the project being developed. For example, the Firmware Support Manual will not be required if no firmware is being developed: or two design reviews (POR and COR) may not be necessary for a small project.
- Prepare a list of requests for deletions from the standard. This may include:
exclusion of documents exclusion of sections in documents exclusion of activities. exclusion of parts of activities
- Prepare a written description of the justifications for each item that is requested to be tailored out.
- Submit the tailoring request, together with the justification, as early as possible (preferably before the project begins).
In order to be able to differentiate between forgotten items and tailored items, all tailored items must be clearly referenced. When submitting a list of documents for a formal review or milestone, all documents tailored out should be listed together with a statement to that effect. Within a document, when a paragraph is tailored out a statement to that effect will appear directly after the paragraph number. If a paragraph and all of its subparagraphs are tailored out, only the highest level paragraph number need be included.
The list of the DID s together with the list of tailoring approvals are an integral part of the project deliverables. Until tailoring approval has been granted, the developer is obligated to provide the full list of Dills, with all their inclusions. This is the reason why tailoring should be concluded as early as possible.
6. The software configuration management plan (SCMP)
The software configuration management plan (SCMP) is part of the project's software development plan. The SCMP may appear as a separate document or as a section within the project development plan.
The SCMP documents the resources that are needed, how they are to be used, and which standards and procedures will be applied during the project.
docsity.com
The SCMP then becomes the mandate for the configuration control group during project development. The issuance of this plan is the responsibility of the project manager, though in large projects it may be delegated to the configuration Control manager.
Table 4 contains a list of the main subjects covered in the SCMP. When any of these subjects is covered elsewhere (e.g. in the software quality assurance plan), it can be omitted from the SCMP and replaced by a pointer to the document in which it is covered. Though most of the subjects in Table 1 are self-descriptive, the following are some guidelines:
Configuration status accounting describes the way in which status information flows:
From the developers to the configuration management organization (audits and reviews) From the configuration management organization to project management (status reporting procedures)
Configuration identification describes the method for designating development items as SCCI s. This is part of the high level decomposition of the system into major development components.
The section on identification methods describes the way in which each component generated by the project is marked for unique identification. Security, restricted access and classification refer to the secure development of sensitive products (such as documents, software, patents, military classified information etc.). It is often convenient to assign many of these tasks to configuration control because of the need to be involved in the review and classification of documents and other related activities that are associated with security.
Subcontractors, vendors and suppliers mayor may not implement their own configuration management plan. It is the project manager's responsibility to assure that either subcontractors or external developers submit a CMP for review, or that the project's configuration manager assumes responsibility for their work.
The SCMP may also include diagrams and flow charts to describe procedures for submitting change requests, or for reporting problems.
7. Statistical software process improvement (SSPI)
As an organization becomes more comfortable with the collection and use or process metrics, the derivation of simple indicators gives way to a more rigorous approach called statistical software process improvement (SSPI).
docsity.com
**9. Configuration control of subcontractors, vendors and suppliers
- Additional control** Miscellaneous control procedures Project specific control (security etc) 11. Configuration status accounting Configuration audits and reviews Configuration structure reporting procedures **12. Configuration management major milestones
- Tools, techniques and methodologies** 8. Communications management plan
A communications management plan is a document that provides:
- A collection and filing structure that details what methods will be used to gather and store various types of information. Procedures should also cover collecting and disseminating updates and corrections to previously distributed material. - A distribution structure that, details to whom information (status reports, data, schedule, technical documentation, etc.) will flow, and what methods (written reports, meetings, etc.) will be used to distribute various types of information. This structure must be compatible with the responsibilities and reporting relationships described by the project organization chart. - A description of the information to be distributed, including format, content, level of detail, and conventions/definitions to be used. - Production schedules showing when each type of communication will be produced. - Methods for accessing information between scheduled communications. - A method for updating and refining the communications management plan as the project progresses and develops. The communications management plan may be formal or informal, highly detailed or broadly framed, based on the needs of the project. It is a subsidiary component of the overall project plan. 9. The software quality assurance plan
Every project must have a quality plan. The quality plan will be presented as a section in the project plan.
docsity.com
It is drawn up by the project manager at the start of the project and should be agreed with the project sponsor.
You would expect the quality plan to contain the following elements:
Statement of the quality control organisation Identification of specific standards and methods that will be used Definition of the quality control procedures; this is aligned to the Work Breakdown Structure Specification of quality milestones Detail of unusual features Change control and configuration management Detail of acceptance procedures Specification of quality assurance procedures
The software quality assurance plan (SQAP), like the software configuration plan, is also part of the overall software project development plan.
The SQAP documents which resources are needed, how they should be used and which standards and procedures will be applied during the project.
The SQAP then becomes the mandate for the quality assurance group during project development. The issuance of this plan is the responsibility of the project manager, though in large projects it will usually be delegated to the quality assurance manager.
The SQAP may appear as a separate document or as a section within the project development plan, and may include the configuration management plan (if this has not been documented separately).
Table 5 contains a list of the main subjects covered in the SQAP. When any of these subjects is covered elsewhere, such as in the software configuration management plan (SCMP), it can be omitted from the SQAP and replaced by a pointer to the document in which it is covered.
However, the SCMP and the SQAP are concerned with different aspects of the controlled items. The SCMP is primarily concerned with the format of controlled items while the SQAP is more involved with the contents of controlled items.
The SQAP must cover subcontractors, vendors and suppliers, irrespective of whether or not these external entities have their own quality assurance organization.
In any project, the quality of external components is ultimately the concern of the project manager and the SQA organization. When a system fails, it usually makes
docsity.com
