Software Project Management Unit 1

Evolving role of software S/w now a days resides in the mobile, mainframes The main role of the s/w is to transform the INFORMATION Information can be producing, managing, acquiring, modifying, displaying, or transmitting information S/w also act as basis for controller of computer, communication of information, creation and control of other program

What is Software? The Software is: 1.Instruction that when executed provides desired function and performance 2.Data Structure that enables the program to adequately manipulate information 3.Documents that describe the operation and use of the program

Software Myths [FAQ] S/w myth are the concepts which are heeding within the managers and developers of the software which can make the s/w devlopment process erroneous Types of S/w myths : 1. Practitioner myth 2. Customer myth 3. Management myth

Practitioner myth Practitioners means the programmers who develop the s/w Myth #1: Once we write the program and get it work our work is done Reality: 60 to 80 of the effort and expenditure on the s/w is done after the s/w is delivered to the customer Myth #2: Until I get the s/w running I can’t check the s/w quality Reality: S/w quality assurance process is started from gathering the customer requirement

Practitioner myth Myth #3: The only delivered for the s/w project is the “working program” Reality: Working program is the only part of the software project development. It also contains the documentation, user manuals, license agreement etc Myth #4: Software engineering will create unnecessary documentation that will slow down the development of s/w Reality: S/w engineering is not about creating the documents but about creating quality

Customer myth Customer is the person who gives the requirement to the s/w developer and contracted the s/w development Myth #1: A general statement of requirement is enough to start the development of s/w Reality: A detailed and formal description of domain, function, design of s/w is required Myth #2: Project requirements can be change and these changes can be easily accommodated Reality: Changes in the s/w can be accepted if they are reported by the customer at early stages of s/w development

Management myth Managers are responsible to maintain budgets, keep scheduling, improve quality Myth #1: The standards of s/w development are know by the s/w developers Reality: The s/w developer are unknown about the standard of the s/w development Myth #2: My people have the updated s/w development tools and we will buy new computers for quality s/w development Reality: Latest computer and updated development tools doesn't guarantee quality software product

Management myth Myth # 3: If we get behind the schedule then we can add the more people and catch up Reality: Adding new people to the late project makes it later Myth # 4: If we decide to outsource the project then we can relax Reality: Software firm has to manage its s/w project internally though it had outsourced it

Software Engineering [FAQ] Software engineering means applying the engineering principles in order to obtain the economical s/w that is reliable and runs efficiently on the machine. S/w engineering layers:- “Quality” focus “Quality” focus Tools Methods Process model

Software Engineering Software engineering is the layered technology which is based on the bedrock of Quality focus Process defines the framework which is use to define the work product, define the documents, manage the quality Method provides the technical “how to” built the s/w, it contains the task like requirement analysis, design, coding, testing etc. Tools provide the automated or semi automated support for process and method. It consist of s/w development programs like compilers etc.

Software Process

Software Process [FAQ] Five Activities of a Process framework: 1.Communication: communicate with customer to understand objectives and gather requirements 2.Planning: creates a “map” defines the work by describing the tasks, risks and resources, work products and work schedule. 3.Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts fit together and other characteristics. 4.Construction: code generation and the testing. 5.Deployment: Delivered to the customer who evaluates the products and provides feedback based on the evaluation.

Umbrella Activities Complement the five process framework activities Software project tracking and control: assess progress against the plan and take actions to maintain the schedule. Risk management: assesses risks that may affect the outcome and quality. Software quality assurance: defines and conduct activities to ensure quality. Technical reviews: assesses work products to uncover and remove errors before going to the next activity. Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met. Work product preparation and production: create work products such as models, documents, logs, forms and lists.

Capability Maturity Model [CMM] S/w Engg Institute (SEI) developed the CMM so that it can grade the process maturity used in the project CMM is use to grade the companies s/w development process. S/w companies try to improve their s/w development process and upgrade the CMM levels It provide the measure of effectiveness of companies s/w engg practices and established the five process maturity levels:

Capability Maturity Model [CMM] Level 1: Initial : The s/w process is ad hoc or chaotic, very few process are defined Level 2: Repeatable: Basic processes are applied to track the cost, schedule, etc. Level 3: Defined. The software process is documented, standardized, and integrated. All projects use a documented and approved process for developing and supporting software. This level includes all characteristics defined for level 2. Level 4: Managed. Detailed measures of the software process and product quality are collected. This level includes all characteristics defined for level 3. Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from testing. This level includes all characteristics defined for level 4.

Software Process Model Process model is the strategy or methodology used by the developer to develop the s/w. Software Process models consist of the process, methods and tools layers to develop the software A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.

The Linear Sequential model It is the oldest process models in SE history Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic, sequential approach to software development

Waterfall Model Analysis Design Code Test

The Linear Sequential model The linear sequential model encompasses the following activities: 1.System/information engineering and modeling: work begins by establishing requirements for all system elements 2.Software requirements analysis: Requirements for both the system and the software are documented and reviewed with the customer

3.Design: Software design is actually a multistep process that focuses on four distinct attributes of a program: data structure, software architecture, interface representations and program 4.Code generation: The design must be translated into a machine-readable form. 5.Testing: Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software 6.Support. Software will undoubtedly undergo change after it is delivered to the customer The Linear Sequential model

Disadvantage: 1.Real projects rarely follow the sequential flow 2.It is often difficult for the customer to state all requirements explicitly at the beginning. 3.The customer must have patience. A working version of the program will not be available until project is completed 4.Classic life cycle leads to “blocking states” in which some project team members must wait for other members of the team to complete dependent tasks The Linear Sequential model

Prototyping Model

The RAD Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle The RAD model is a “high-speed” adaptation of the linear sequential model Rapid development is achieved by using component-based construction The RAD process enables a development team to create a “fully functional system” within very short time periods (e.g., 60 to 90 days)

The RAD Model

The RAD approach has drawbacks: For large projects, RAD requires sufficient human resources to create the right number of RAD teams Not all types of applications are appropriate for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use of new technology

Evolutionary Process Model

Spiral Model

The four P’s The s/w project consist of four P’s: 1.People 2.Product 3.Process 4.Project

The People Managing people in the industry is one of the crucial aspect of s/w project Recruiting, selection, performance management, training, compensation, career development are the major activities. People involved: 1.Senior Managers 2.Project Manger 3.Practitioners 4.Customer 5.End User

The Product Before project starts the product objectives must be established. Without this information the estimation of the cost of project, schedule of project cant be done. Customer and developer must meet to define the project objective. Objective identify the goals without considering how these goals will be achieved. The s/w product is decomposed to understand the functionality that must be delivered and process that need to follow.

The Process S/w process provide the framework from which the plan for proj can be made. Small framework activities, umbrella activities, task set such as documentation, SQA are included in the process of s/w project The major task of the s/w proj is to decide the proper process model for the project. Once the process model is decided, the team decides the project plan, and then process is decomposed i.e. plan with task and activity is generated.

The Project In order to make the s/w project successful the proj manager must consider: 1.Start at right foot 2.Maintain momentum 3.Track progress 4.Make smart decision 5.Conduct postmortem analysis

The W 5 HH Principle Barry Boehm developed the series of questions that leads to definition of key project characteristic and proj plan These principle are applicable regardless the size of project or complexity of project. The questions noted provide the excellent planning outline for the project manager and s/w team.

1.Why is system being developed? 2.What will be done, by When? 3.Who is responsible for function? 4.Where are they organizationally located? 5.How will job be done technically and managerially? 6.How much of each resources is needed? The W 5 HH Principle