SlideShare a Scribd company logo

SOFTWARE ENGINEERING

•
•
Gaditek
Gaditek

This slide is for software engineering subject which may help you to better understanding. You can also gain knowledge in software engineering subject.

Software
1 of 290
Download to read offline
Course Title: Software Engineering I Prerequisites: Object Oriented Language Degree: BSC [ Bachelor of Computer Science ] Duration: 18 weeks in Seven semester Lectures: 48 in total, 3 per week, including some examples. Laboratories: none
Introduction to Software Project Management Software Management Project Set of instruction with well define date structure & Algorithms A Specific plan or design or planned activity. The act of managing something
Characteristics of Software Project : • Non routine tasks are involved. • Planning is required. • The project has a pre-determined time span. • Work is carried out for someone other than yourself Software Project: A Specific plan or design or planned activity.
Characteristics of Software Project : • Work involves several specialists. • Work is carried out in several phases. • The project is large or complex. • The resources that are available for use on the project are constrained. • Specific object are to be met or a specified product is o be created.
Software Projects Versus other types of Project Software Project Essence Invisibility Conformity Flexibility/Changeability Complexity Project Visible Inflexible Complexity
What is Management? Planning: deciding what is to be done. Organizing: making arrangements Staffing: Selecting the right people for the job. Directing: giving instructions. Monitoring: Checking on progress. Controlling: taking action to remedy hold-ups. Innovation: coming up with new solutions. Representing: liaising with users.
Management Project Management Software Project Management Software Project Management
Software Development and Project Management: Issues and Global Standards • Not only writing Code ? • Careful Analysis of Requirements • Fitting Requirements in Documentation Template • Design based on time frame and costing • Quality Assurance • Standard Testing • Maintenance
Introduction to Software Project Management Goals – Software delivered within budget – Software delivered within schedule – Software is built according to requirements Why? – Well-managed projects sometimes fail – Badly managed projects inevitably fail – Software development process is not standardized
Main causes of software failures Customer needs are misunderstood or not fully captured; Customer requirements change too frequently; Customers are not prepared to commit sufficient resources to the project; Customers do not want to cooperate with developers; Customers have unrealistic expectations; The system is no longer in benefit to customers; The developers may not be up to the task.
Why Do Projects Succeed? How to identify a projects success potential – What metrics could you look at? • Project size • Project duration • Project team size • Executive support • User involvement • Experience project manager • Clear business objectives • Minimized scope • Standard software infrastructure • Firm basic requirements • Formal methodology • Reliable estimates
Why Executive Support? Top management can help to: – Secure adequate resources – Get approval for unique project needs in a timely manner – Receive cooperation from people throughout the organization – Provide leadership guidance
Project Manager Responsibilities • Proposal Writing • Project Costing • Project Planning & Scheduling • Project Monitoring & Reviews • Personnel Selection & Evaluation • Report Writing & Presentations
– Understand the four P‟s: • People – must be organized to work effectively • Product – must have effective communication with the customer to specify scope and requirements • Process – must be appropriate for people and product • Project – must estimate effort and time needed, define work products, establish quality checkpoints, establish methods to monitor and control work defined by plan
The software accidents Stakeholders Process Modeling language and tools Stakeholders Two groups Customers Users System owners Developers Analysts Designers Programmers, etc.
Process Process for: Order of activities Product delivery (what, when) Assignment to developers Monitoring  measuring  planning • Cannot be codified or standardized • Process and project size • Iterative and incremental Software process models are general approaches for organizing a Project into activities.
Process – Help the project manager and his or her team to decide: • What work should be done; • In what sequence to perform the work. – The models should be seen as aids to thinking, not rigid prescriptions of the way to do things. – Each project ends up with its own unique plan.
The opportunistic approach Think of Idea for Improvement Modify Until Satisfied First Prototype
The opportunistic approach … is what occurs when an organization does not follow good engineering practices. – It does not acknowledge the importance of working out the requirements and the design before implementing a system. – The design of software deteriorates faster if it is not well designed. – Since there are no plans, there is nothing to aim towards. – There is no explicit recognition of the need for systematic testing and other forms of quality assurance. – The above problems make the cost of developing and maintaining software very high.
The waterfall model The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance. – The model suggests that software engineers should work in a series of stages. – Before completing each stage, they should perform quality assurance (verification and validation). – The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.
The waterfall model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Maintenance V & V Integration and Deployment
Limitations of the waterfall model – The model implies that you should attempt to complete a given stage before moving on to the next stage • Does not account for the fact that requirements constantly change. • It also means that customers can not use anything until the entire system is complete. – The model makes no allowances for prototyping. – It implies that you can get the requirements right by simply writing them down and reviewing them. – The model implies that once the product is finished, everything else is maintenance.
The phased-release model It introduces the notion of incremental development. – After requirements gathering and planning, the project should be broken into separate subprojects, or phases. – Each phase can be released to customers when ready. – Parts of the system will be available earlier than when using a strict waterfall approach. – However, it continues to suggest that all requirements be finalized at the start of development.
The phased-release model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Planning Phase 1 V & V Design V & V Implementation Phase 2 etc ... V & V Integration and Deployment V & V Integration and Deployment
The spiral model It explicitly embraces prototyping and an iterative approach to software development. – Start by developing a small prototype. – Followed by a mini-waterfall process, primarily to gather requirements. – Then, the first prototype is reviewed. – In subsequent loops, the project team performs further requirements, design, implementation and review. – The first thing to do before embarking on each new loop is risk analysis. – Maintenance is simply a type of on-going development.
The spiral model Requirements Specification Design Implementation Prototype Release 1 Release 2 Review Analysis of risk Integration and deployment
The evolutionary model It shows software development as a series of hills, each representing a separate loop of the spiral. – Shows that loops, or releases, tend to overlap each other. – Makes it clear that development work tends to reach a peak, at around the time of the deadline for completion. – Shows that each prototype or release can take • different amounts of time to deliver; • differing amounts of effort.
The evolutionary model Time Development Activity
The concurrent engineering model It explicitly accounts for the divide and conquer principle. – Each team works on its own component, typically following a spiral or evolutionary approach. – There has to be some initial planning, and periodic integration.
The concurrent engineering model Plan Integrate Divide Work on Component or Layer X Work on Component or Layer B Work on Component or Layer A ...
Choosing a process model – From the waterfall model: • Incorporate the notion of stages. – From the phased-release model: • Incorporate the notion of doing some initial high-level analysis, and then dividing the project into releases. – From the spiral model: • Incorporate prototyping and risk analysis. – From the evolutionary model: • Incorporate the notion of varying amounts of time and work, with overlapping releases. – From the concurrent engineering: • Incorporate the notion of breaking the system down into components and developing them in parallel.
Reengineering Periodically project managers should set aside some time to re-engineer part or all of the system – The extent of this work can vary considerably: • Cleaning up the code to make it more readable. • Completely replacing a layer. • Re-factoring part of the design. – In general, the objective of a re-engineering activity is to increase maintainability.
Software development invariant Software production is an art – Software is developed, not manufactured …but we can customize: • Re-use (algorithms, code libraries, classes, software) • COTS (commercial-of-the-shelf solutions) • ERP (Enterprise Resource Planning systems) – … but what about core business? • Component technology – CORBA – DCOM – EJB
People in the process People are an organisation‟s most important assets. The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. Poor people management is an important contributor to project failure.
People management factors Consistency – Team members should all be treated in a comparable way without favourites or discrimination. Respect – Different team members have different skills and these differences should be respected. Inclusion – Involve all team members and make sure that people‟s views are considered. Honesty – You should always be honest about what is going well and what is going badly in a project.
Selecting staff An important project management task is team selection. Information on selection comes from: – Information provided by the candidates. – Information gained by interviewing and talking with candidates. – Recommendations and comments from other people who know or who have worked with the candidates.
Project staffing May not be possible to appoint the ideal people to work on a project – Project budget may not allow for the use of highly-paid staff; – Staff with the appropriate experience may not be available; – An organisation may wish to develop employee skills on a software project. Managers have to work within these constraints especially when there are shortages of trained staff.
Building Software Engineering Teams Software engineering is a human process. – Choosing appropriate people for a team, and assigning roles and responsibilities to the team members, is therefore an important project management skill – Software engineering teams can be organized in many different ways on the basis of problem of different complexities and sizes.
Types of Development Team Closed (tactical) traditional leadership stable and secure can be over-controlled operates in a group-oriented way good for routine projects Random (breakthrough) bottom-up decision making promotes creativity chaotic, competitive operates in a chaotic, undirected way good for creative breakthroughs Open (problem-solving) decision-making by consensus adapt to & solve complex problems chaotic, might not solve anything operates in a flexible, explorative way works best on solving complex problems L. Constantine, 1993. Work Organization: Paradigms for Project Management and Organization. CACM October 1993, pp. 35-44. Synchronous (vision-sharing) decisions implied by visions efficient, smooth can drift, lose sight of reality operates in a coordinated way repetitive problems, high performance
Team Structure • Egoless/Democratic team • Chief-programmer team • Strict hierarchy/Mixed organization a) Egoless b) Chief programmer c) Strict hierarchy
Egoless/Democratic Teams Democratic organization provides – In such a team everybody is equal, and the team works together to achieve a common goal. – Decisions are made by consensus. – Most suited to difficult projects with many technical challenges. – higher morale and job satisfaction to the engineers – therefore leads to less employee turnover. Suitable for less understood problems, – a group of engineers can invent better solutions than a single individual.
Democratic Teams Disadvantage: –team members may waste a lot time arguing about trivial points: •absence of any authority in the team.
Chief Programmer Team A senior engineer provides technical leadership: – partitions the task among the team members. – verifies and integrates the products developed by the members.
Chief Programmer Team Works well when – the task is well understood • also within the intellectual grasp of a single individual, – importance of early completion outweighs other factors • team morale, personal development, etc.
Chief programmer team is subject to single point failure: – too much responsibility and authority is assigned to the chief programmer. Chief Programmer Team
Group Leadership Leadership depends on respect. What kind of leadership? – Technical – Administrative – Co-leaders – Collective leadership Democratic is better than autocratic.
The Team Leader Project management is a people-oriented activity – People with great technical skills don‟t necessarily make good team leaders – people skills are needed too Weinberg suggests an MOI model of leadership – Motivation • Ability to encourage technical people to work to the best of their abilities (push or pull) – Organization • Ability to adapt existing processes, or devise new ones, to enable the concept to be turned into a product – Ideas/Innovation • Ability to encourage people to create, and to feel creative, within the bounds of the particular product Team leader must let everyone know, by words and deeds, that quality is important – lead by example!
The Team Leader Another view of what makes a good team leader: – Problem solving • Decide which technical and organizational issues are most important • Create a systematic solution to the problem – or motivate others to do so • Apply lessons from past projects to new ones • Remain flexible enough to change direction if initial proposed solution doesn‟t work – Managerial Identity • Confidence to take charge of project when necessary, but also to let good technical people use their initiative – Achievement • Reward initiative and accomplishment • Demonstrate that controlled risk-taking will not be punished – Influence and Team building • Be able to “read” people – understand both verbal and non-verbal signals from team members, and react to their needs
Strict hierarchy/Mixed Control Team Organization Draws upon ideas from both: – democratic organization and – chief-programmer team organization. Communication is limited – to a small group that is most likely to benefit from it. Suitable for large organizations
Choosing an effective size for a team – For a given estimated development effort, in person months, there is an optimal team size. • Doubling the size of a team will not halve the development time. – Subsystems and teams should be sized such that the total amount of required knowledge and exchange of information is reduced. – For a given project or project iteration, the number of people on a team will not be constant. – You can not generally add people if you get behind schedule, in the hope of catching up.
Skills needed on a team – Architect – Project manager – Configuration management and build specialist – User interface specialist – Technology specialist – Hardware and third-party software specialist – User documentation specialist – Tester
Motivating people An important role of a manager is to motivate the people working on a project. Motivation is a complex issue but it appears that their are different types of motivation based on: – Basic needs (e.g. food, sleep, etc.); – Personal needs (e.g. respect, self-esteem); – Social needs (e.g. to be accepted as part of a group).
Human needs hierarchy Ph ysiolo g ical need s Safety need s So cial n eeds Esteemn eeds Self- r ealisa tion needs
Need satisfaction Social – Provide communal facilities; – Allow informal communications. Esteem – Recognition of achievements; – Appropriate rewards. Self-realization – Training - people want to learn more; – Responsibility.
Personality types The needs hierarchy is almost certainly an over-simplification of motivation in practice. Motivation should also take into account different personality types: – Task-oriented; – Self-oriented; – Interaction-oriented.
Personality types Task-oriented. – The motivation for doing the work is the work itself; Self-oriented. – The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc.; Interaction-oriented – The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work.
Motivation balance Individual motivations are made up of elements of each class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal factors but also by being part of a group and culture. People go to work because they are motivated by the people that they work with.
Managing groups Most software engineering is a group activity – The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. Group interaction is a key determinant of group performance. Flexibility in group composition is limited – Managers must do the best they can with available people.
Factors influencing group working Group composition. Group cohesiveness. Group communications. Group organisation.
Group composition Group composed of members who share the same motivation can be problematic – Task-oriented - everyone wants to do their own thing; – Self-oriented - everyone wants to be the boss; – Interaction-oriented - too much chatting, not enough work. An effective group has a balance of all types. This can be difficult to achieve software engineers are often task-oriented. Interaction-oriented people are very important as they can detect and defuse tensions that arise.
Leadership depends on respect not titular status. There may be both a technical and an administrative leader. Democratic leadership is more effective that autocratic leadership. Group leadership
Group cohesiveness In a cohesive group, members consider the group to be more important than any individual in it. The advantages of a cohesive group are: – Group quality standards can be developed; – Group members work closely together so inhibitions caused by ignorance are reduced; – Team members learn from each other and get to know each other‟s work; – Egoless programming where members strive to improve each other‟s programs can be practised.
Developing cohesiveness Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group. Cohesiveness can be encouraged through – Social events; – Developing a group identity and territory; – Explicit team-building activities. Openness with information is a simple way of ensuring all group members feel part of the group.
Group members tend to be loyal to cohesive groups. 'Groupthink' is preservation of group irrespective of technical or organizational considerations. Management should act positively to avoid groupthink by forcing external involvement with each group. Group loyalties
Group communications Good communications are essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions. Good communications also strengthens group cohesion as it promotes understanding.
Group size – The larger the group, the harder it is for people to communicate with other group members. Group structure – Communication is better in informally structured groups than in hierarchically structured groups. Group composition – Communication is better when there are different personality types in a group and when groups are mixed rather than single sex. The physical work environment – Good workplace organisation can help encourage communications. Group communications
Group organisation Small software engineering groups are usually organised informally without a rigid structure. For large projects, there may be a hierarchical structure where different groups are responsible for different sub- projects.
Informal groups The group acts as a whole and comes to a consensus on decisions affecting the system. The group leader serves as the external interface of the group but does not allocate specific work items. Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience. This approach is successful for groups where all members are experienced and competent.
Extreme programming groups Extreme programming groups are variants of an informal, democratic organisation. In extreme programming groups, some „management‟ decisions are devolved to group members. Programmers work in pairs and take a collective responsibility for code that is developed.
The physical workplace provision has an important effect on individual productivity and satisfaction – Comfort; – Privacy; – Facilities. Health and safety considerations must be taken into account – Lighting; – Heating; – Furniture. Working environments
Privacy - each engineer requires an area for uninterrupted work. Outside awareness - people prefer to work in natural light. Personalization - individuals adopt different working practices and like to organize their environment in different ways. Environmental factors
Workspace organisation Workspaces should provide private spaces where people can work without interruption – Providing individual offices for staff has been shown to increase productivity. However, teams working together also require spaces where formal and informal meetings can be held.
Office layout
Sample sets of tasks – Meet with client and decide on scope of project – Develop information gathering plan – Design survey – Get authorization for survey – Pilot-test survey – Revise survey – Select sample for survey – Administer survey – Analyze survey results – Compile list of candidate systems – Develop template for comparing alternatives – Decide on "short list" – Do detailed technical analysis of alternatives – Do detailed cost analysis of alternatives
Sample sets of tasks Tasks (continued) – Draft comparative sections of report – Revise comparative sections of report – Write implementation plan – Write evaluation plan – Write final report – Prepare oral presentation And here are the milestones: – Submit information gathering protocol and instrument – Submit progress report – Submit economic feasibility report – Submit process diagram(s) – Submit final report – Give oral presentation
Project Scope In Traditional Project Management (TPM), it is assumed that you can determine the goal of the project from the onset – The adaptive or extreme management methods examined later will allow this not to be true Capture key project objectives in the Project Overview Statement (POS)
Role of the POS The POS captures key objectives of the project, such as the Conditions of Satisfaction (COS) – It should be a short document (1-2 pp) – The COS should convey what the project is expected to deliver and accomplish – It should be reviewed and updated throughout the project – it isn‟t static – It is negotiated with the customer
Role of the POS The POS is a communications tool among the project manager, their development team, the customer, and the project manager‟s boss (upper or senior management) The POS is a concise statement of the project, and a summary of its justification to continue
Other Views The POS and COS are often known by other terms, like the Vision or Mission of the project – POS and COS are Wysocki‟s terminology
Generating the POS Often the POS is developed through an iterative process – The customer makes a request for some major aspect of the product (key set of features, for example) – The developer asks to clarify the request – The customer provides a response – Customer and developer agree on the response – Repeat the previous four steps until done
Non-traditional POS Uses The POS can help understand a project even if not starting from scratch – Inheriting a project from someone else – Using a POS as a suggestion to start an unsolicited project – Use a POS as a reference to guide your team during development
Parts of a POS The POS has five major sections – Problem/opportunity – Goal – Objectives – Success criteria – Assumptions, risks, obstacles Each is typically a few paragraphs long
Problem/opportunity This section summarizes major problems the project will fix, and identify significant new opportunities of which it will take advantage – Like the INFO 503 analysis method of the same name, this helps prove there is significant motivation for the project to occur
Goal The goal gives direction and purpose to the project, summarizing how the organization will address the problems, or act on the opportunities Don‟t commit to specific time or cost goals – the scope of the project is too vague for that
Objectives The objective statements elaborate on the goal, and clarify its scope or boundaries – If you meet all the objectives, then the goal must also be met – Each objective should define an expected outcome, the rough time frame it will be done, a measure, and the action needed to meet the objective
Success criteria Imagine the project is done, and you want to prove how much the organization benefited from it – What specific measures could you make to prove the project was worthwhile? – These are your success criteria Typical criteria are increased revenue, reduced costs, improved service, etc.
Assumptions, risks, obstacles This is an executive summary of major assumptions the project is based upon, key risks to manage, and foreseeable obstacles that will need to be overcome – Particularly focus on areas you might need help managing More details will appear in the Project Definition Statement (PDS)
POS Attachments The POS can have attachments for more information on the project Most common are – A risk analysis (to show more detail than given earlier), and/or – A financial analysis (such as cost-benefit analysis, feasibility studies, ROI, etc.)
POS Approval The POS is submitted to middle or upper management for approval The expected outcome is to continue more detailed planning and analysis for the project
Expand POS into PDS The Project Definition Statement (PDS) expands on the POS in two key areas – Objectives can be more specific, and use more technical language to convey their exact intent – Assumptions, risks, obstacles can cover more details of interest to the development team
Project Reviews and Meetings
Objectives What Software Project Managers need to know to: Identify the types of reviews and meetings Understand when and why to hold reviews and meetings Use the 10 Steps to productive reviews and meetings
Types of Reviews and Meetings Technical Reviews Address technical issues: requirements, design, code Example: Formal Inspections Management Reviews Address project issues: status, budget, schedule Example: Design Review Meetings Gathering of people for a business purpose Examples: staff meetings, committee meetings, training sessions
Technical Reviews • Address technical issues: evolving software products, services, solutions • Are attended only by persons with technical knowledge of the subject matter, not management - Includes both acquirer and developer technical personnel - In requirements phase includes customers, users - Includes SQA, SCM, V&V, test as needed • Report the actual technical status of the project to management • Identify risks and issues to be raised at Management Reviews • Examples: Formal Inspection Code walkthrough Design tradeoff meeting Process review
Technical Review Criteria for a Software Product or Service Is it complete? Does it comply with standards and specifications? Are changes properly implemented? Does it adhere to the applicable schedule? Is it ready for the next planned activity? Is development being conducted according to the plans, standards, and guidelines of the project?
Technical Reviews provide inputs to Management Reviews Technical Review resolve defects Technical Review resolve defects Prelim I’face Spec. Management Review (software design review) Technical Review resolve defects Plan Prelim Reqts. Spec. status risks issues concerns questions
Management Reviews • Address project issues: status versus plans, schedules, standards • Keep management informed about status, direction, agreements • Are attended by technical leaders, project managers, and managers (with decision authority over cost and schedule) • Identify and resolve risks - Are we ready to continue? Should we continue? • Receive input, resolve issues from several Technical Reviews • Examples: Requirements review Design review Test readiness review
Management Review Criteria Is progress according to plan? Are schedules, standards, and guidelines being followed? Are resources adequately allocated? Are risks jeapordizing success? Are we making good decisions based on metrics? Do we need to change direction or revise plans?
Management Review Terminology DOD-STD-2167A MIL-STD-498 IEEE/EIA 12207 Formal Reviews (10) Joint Mgmt. Reviews (11) Project mgmt. reviews (11) Software plan review Software plan review Operational concept review Operational concept review System Reqts. Rev.(SRR) System/subsys. reqts rev. System/subsys. reqts rev. System Design Rev.(SDR) System/subsys. design rev. System/subsys design rev. Software Spec. Rev. (SSR) Software reqts review Software reqts. review Prelim Design Rev. (PDR) Critical Design Rev. (CDR) Software design review Software design review Test Readiness Rev. (TRR) Test readiness review Test readiness review Test results review Test results review Production Readiness Rev(PRR) -- -- Software usability review Software maintenance rev. Software supportability rev. Software supportability rev. Critical reqts. review Critical reqts. review Functional Config Audit (FCA) (FCA in MIL-STD-973) (FCA in IEEE Std 1042) Physical Config Audit (PCA) (PCA in MIL-STD-973) (PCA in IEEE Std 1042) Formal Qual. Review (FQR) (dropped by MIL-STD-073) -- (see MIL-STD-1521B) (see 498 Appendix E) (see 12207.2 Annex G) (see also IEEE Std 1028)
SSC SD Management Project/Design Reviews SPAWARSYSCEN SAN DIEGO INST 3912.1A of 18 Dec 1997 Development projects will be subject to periodic review Purpose: to help project managers meet cost, schedule, and technical requirements SC SD Department Heads to identify applicable projects Program Managers to adhere to policies and procedures Design Review Committee to coordinate reviews Review topics: Management practices Technical processes Requirements and approaches Test and evaluation Schedule and budget Documentation plans/status Procurement status Product assurance plans/status Instruction available at: http://iweb.spawar.navy.mil/services/sti/publications/inst/subjects.html
Purposes: Convey information to a group Solicit information Answer questions Brainstorm Make a decision as a group Convince or persuade team of idea Maintain team spirit, involvement Examples: Weekly Status Meeting All-Hands Meeting Committee Meeting “Are you lonely? Working on your own? Hate making decisions? HOLD A MEETING!” Meetings
Question: What are the Consequences of Poorly- Run Reviews and Meetings?
The Steps to Successful Reviews and Meetings
• Determine type of review/meeting: Technical Review, Management Review, program review, status meeting, staff meeting, etc. • What outcome or decision do you expect to reach? • Should be goal-oriented, value-added, and primarily non-adversarial Examples: “Reach agreement on interface requirements.” “Review project status and risks to determine if requirements need to be reduced.” “Announce the new project organization and decide on new office spaces.” Step 1: Establish Type of Review/Meeting and the G______ and O____________
Step 2: Establish E_______ C_________ and E______ C_________ • Entrance criteria: What must occur prior to the review or meeting in order to make it successful Derived from goals/objectives Examples: Completion of the work product to be approved All attendees read IRS, review risks • Exit criteria: What must be accomplished for the review or meeting to be closed Example: Identify and document all discrepancies • Both must be established prior to review/meeting
Step 3: Be Organized; Be Prepared • Select the right participants - get a good mix - Invite only those who have a stake in the outcome - Continuity of participants is important!! • Assign roles: leader, facilitator, timekeeper, recorder • Have an agenda - keep to it - Hand out agenda ahead of time • Insist that participants be prepared
Step 4: * Hold a kick-off meeting for Reviews • Review goals/objectives of the review with the developer (participants) - Schedule at least two weeks prior to the meeting - Doesn’t have to be face-to-face in the same room, could be video teleconference or phone call Example: Formal Inspection Overview Meeting * - applies to reviews only
Step 5: *Hold a Government-only pre-review meeting (if applicable) • Evaluate goals/objectives of the review, controversial areas, known deficiencies • Purpose is to achieve Government consensus • Most important if multiple Government agencies are involved * - applies to Management Review only
Step 6: Get Off to a Good Start • Make the participants feel comfortable - Ensure adequate facilities (space, lights, air conditioning, ...) - Set up room to accommodate the objective (for best communications, use U-shaped or oval) • Arrange for food, drinks, breaks • Provide welcome and introductions • Summarize roles, goals, objectives, agenda • Verify that Entrance Criteria have been met
Step 7: Establish Ground Rules • Getting everyone’s input - Use round robin or query those not contributing - Show appreciation for constructive participation - Encourage open communication - Use everyone’s talents--that is why they are there • Limiting the number and length of presentations - Agree on time limits, assign timekeeper • Controlling the group size - If the group is over 10, divide the group into smaller teams to divide up the issue to be discussed • Using prototypes to assist participants in understanding and communication • Handling disagreements or conflicts
Step 8: Take M__________ of Proceedings and Assign A________ I________ • Sample contents: Review name and objectives Attendees Results and Decisions Action Items •Assign action items for open issues - Specify due date, priority, and responsible person • Review action items and decisions prior to close of review/meeting - Action Items that can be answered during the review/meeting should be answered then and allow time for more detailed analysis of more profound Action Items • Confirm that Exit Criteria are met • Send out minutes in a timely manner for review and comment
Step 9: Request F__________ on how to improve the review/meeting process • Reviews and meetings span the life of all projects • All attendees want reviews and meetings to be productive • Example feedback questions - Was the agenda available beforehand? - How can we foster better communication? - Do we have the right attendees? - Were the physical facilities adequate? - How can our reviews and meetings be improved?
Step 10: Track, Follow-up on A_______ I______ • Establish an Action Item tracking system Sample Contents: A.I. number Description Priority Date Assigned Responsible person(s) Estimated Completion Date Status Date Closed • Collect the metric: outstanding action items - Measures the health of a software project • Schedule an in-progress (status) review or meeting if needed • Prepare for next review/meeting
Summary: The Steps to Successful Reviews and Meetings 1. Establish type of review/meeting and the goals and objectives 2. Establish entrance criteria and exit criteria 3. Be organized, be prepared 4. Hold a kick-off meeting (for Reviews only) 5. Hold a Government-only pre-review meeting (for reviews only) 6. get off to a good start 7. Establish ground rules 8. Take minutes of proceedings and assign action items 9. Request feedback on how to improve the review/meeting process 10. Track, follow up on action items
The Software Project Manager shall: • Conduct reviews and meetings when appropriate • Separate technical reviews from management reviews • Apply the 10 key steps to make them successful
Formal Technical Reviews (FTR) An FTR is a quality assurance activity performed by software engineers (and others) Objectives – Uncover errors in function, logic or implementation for any representation of software – Verify that software being reviewed meets its requirements – Ensure that software is represented according to relevant standards (e.g. Structured A&D, UML) – Achieve uniform software development – Make projects more manageable – Train junior software engineers FTRs include walkthroughs, inspections and other small group software assessments
FTRs: Constraints FTRs are conducted as meetings, and will only be successful if properly planned, controlled and attended Basic constraints for FTRS: – Typically involve three to five people – Participants should do advance preparation (no more than two hours work) – Review meeting should take no more than two hours To meet these constraints, the FTR must focus on a specific (and small) part of the software By reducing scope of the FTR, the chance of uncovering errors is increased
FTRs: Preparation Preparation for an FTR – Person who developed the work product – the producer – informs the team leader that it is ready for review – Team leader designates a review leader, who evaluates the product‟s readiness and distributes copies of product material to two or three other reviewers – Each reviewer spends one or two hours reviewing the product and making notes on it – At the same time, the review leader also reviews the product, establishes an agenda for the review meeting and schedules a meeting time
FTRs: The Meeting The FTR meeting – Meeting is attended by producer, review leader and all reviewers – One reviewer acts as a recorder, who notes in writing all the important issues raised during the review – Start by going over the agenda, and a brief introduction to the product from the producer – Producer then proceeds to “walk-though” the product, explaining it as he/she goes • Reviewers raise issues based on their advance preparation • When valid problems or errors are discovered, they are noted by the recorder – At end of meeting, all participants must decided whether to • Accept the product as is • Reject the product due to severe problems (redevelopment and another review required) • Accept the product provisionally (minor errors, as noted, must be corrected, but no further review required)
FTRs: Reporting Review Reporting and Recording – After the review meeting, the recorder produces a review summary report, answering the questions: • What was reviewed? • Who reviewed it? • What were the findings and conclusions? – Review summary report is typically a single page, possibly with attachments – A review issues list should also be created and attached to the summary report. It notes: • Problem areas within the product • An action item checklist which guides the producer as corrections are made – The review leader should have follow-up contact with the producer to ensure that the issues have been addressed
FTRs: Guidelines Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Identify problem areas but don‟t attempt to solve every problem Take written notes Limit the number of participants Insist on advance preparation Develop a checklist for each work product Allocate resources and time Conduct meaningful training Review earlier reviews
FTRs: Effectiveness Catch up to 75% of design errors Can be up to three times more effective than testing at finding errors Involve time, effort and money, but provide a demonstrable cost benefit in the overall development
Project Agreement Document written for a client that defines: – the scope, duration, cost and deliverables for the project. – the exact items, quantities, delivery dates, delivery location. Client: Individual or organization that specifies the requirements and accepts the project deliverables. Can be a contract, a statement of work, a business plan, or a project charter. Deliverables (= Work Products that will be delivered to the client: – Documents – Demonstrations of function – Demonstration of nonfunctional requirements – Demonstrations of subsystems
Types of Contracts Fixed price or lump sum: involve a fixed total price for a well-defined product or service Cost reimbursable: involve payment to the seller for direct and indirect costs Time and material contracts: hybrid of both fixed price and cost reimbursable, often used by consultants Unit price contracts: require the buyer to pay the seller a predetermined amount per unit of service
Cost Reimbursable Contracts Cost plus incentive fee (CPIF) – Buyer pays seller for allowable performance costs plus a predetermined fee and an incentive bonus Cost plus fixed fee (CPFF) – Buyer pays seller for allowable performance costs plus a fixed fee payment usually based on a percentage of estimated costs Cost plus percentage of costs (CPPC) – Buyer pays seller for allowable performance costs plus a predetermined percentage based on total costs
Contract Types Versus Risk
Statement of Work (SOW) A description of the work required for the project Sets the “boundary conditions” SOW vs. CSOW (Contract SOW) – Latter: uses legal language as part of a competitive bidding scenario Can be used in the final contract – be careful, be specific, be clear
SOW Continued Typically done after approval (after “Go”) Can be multiple versions – 1. List of deliverables for an RFP – 2. More detailed within final RFP – 3. Binding version from contract
SOW Template I. S co p e o f W o rk : D escrib e th e w o rk to b e d o n e to d etail. S p ecify th e h a rd w are an d so ftw are in v o lv ed an d th e ex act n atu re o f th e w o rk . II. L o ca tio n o f W o rk : D escrib e w h ere th e w o rk m u st b e p erfo rm ed . S p ecify th e lo catio n o f h ard w are an d so ftw are an d w h e re th e p eo p le m u st p erfo rm th e w o rk III. P e rio d o f P erfo r m a n c e: S p ecify w h en th e w o rk is ex p ected to start an d en d , w o rk in g h o u rs, n u m b er o f h o u rs th at can b e b illed p er w e ek , w h e re th e w o rk m u st b e p erfo rm ed , an d relate d sch ed u le in fo rm atio n . O p tio n al “C o m p en satio n ” sectio n . IV . D eliv era b les S ch ed u le: L ist sp ecific d eliv erab les, d escrib e th em in d etail, an d sp ecify w h en th e y are d u e. V . A p p lica b le S ta n d a rd s: S p ecify an y co m p an y o r in d u stry -sp e cific stan d ard s th at are relev an t to p e rfo rm in g th e w o rk . O ften an A ssu m p tio n s sectio n as w ell. V I. A ccep ta n c e C riteria : D escrib e h o w th e b u yer o rg an iz atio n w ill d eterm in e if th e w o rk is acc ep tab le. V II. S p ecia l R eq u irem en ts: S p ecify an y sp e cial req u irem en ts su ch as h ard w are o r so ftw are certific atio n s, m in im u m d eg re e o r ex p erien ce lev el o f p e rso n n el, trav el req u irem en ts, d o cu m en ta tio n , testin g , su p p o rt, an d so o n .
Project Charter A high-level project description: – Business need, product, assumptions Often precedes SOW Often 2-4 pages (can be longer)
Project Charter Typical outline – Overview • Business need • Objectives • Method or approach – General scope of work – Rough schedule & budget – Roles & responsibilities – Assumptions
Organization of SPMP Document – Introduction (Objectives,Major Functions,Performance Issues,Management and Technical Constraints) – Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates) – Project Resources Plan(People,Hardware and Software,Special Resources) – Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart Representation) – Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures) – Project Tracking and Control Plan – Miscellaneous Plans(Process Tailoring,Quality Assurance)
Work Breakdown Structure: WBS Hierarchical list of project‟s work activities 2 Formats – Outline (indented format) – Graphical Tree (Organizational Chart) Uses a decimal numbering system – Ex: 3.1.5 – 0 is typically top level Includes – Development, Mgmt., and project support tasks Shows “is contained in” relationships Does not show dependencies or durations
WBS Contract WBS (CWBS) – First 2 or 3 levels – High-level tracking Project WBS (PWBS) – Defined by PM and team members – Tasks tied to deliverables – Lowest level tracking
A Full WBS Structure Up to six levels (3-6 usually) such as Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses – Ex: Level 1: authorizations; 2: budgets; 3: schedules
WBS Chart Example
WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
WBS Types Process WBS • a.k.a Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM Product WBS • a.k.a. Entity-oriented • Ex: Financial engine, Interface system, DB • Typically used by engineering manager Hybrid WBS: both above • This is not unusual • Ex: Lifecycle phases at high level with component or feature-specifics within phases • Rationale: processes produce products
Product WBS
Process WBS
Outline WBS w/Gantt
WBS by PMI Process Groups
WBS Types Less frequently used alternatives – Organizational WBS • Research, Product Design, Engineering, Operations • Can be useful for highly cross-functional projects – Geographical WBS • Can be useful with distributed teams • NYC team, San Jose team, Off-shore team
Work Packages Generic term for discrete tasks with definable end results Typically the “leaves” on the tree The “one-to-two” rule • Often at: 1 or 2 persons for 1 or 2 weeks Basis for monitoring and reporting progress • Can be tied to budget items (charge numbers) • Resources (personnel) assigned Ideally shorter rather than longer • Longer makes in-progress estimates needed • These are more subjective than “done” • 2-3 weeks maximum for software projects • 1 day minimum (occasionally a half day) • Not so small as to micro-manage
WBS List of Activities, not Things List of items can come from many sources – SOW, Proposal, brainstorming, stakeholders, team Describe activities using “bullet language” – Meaningful but terse labels All WBS paths do not have to go to the same level Do not plan more detail than you can manage
WBS & Methodology PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all – Planning, configuration, testing Operations and maintenance phases are not normally in plan (considered post-project) Some models are “straightened” for WBS – Spiral and other iterative models – Linear sequence several times Deliverables of tasks vary by methodology
WBS Techniques Top-Down Bottom-Up Analogy Rolling Wave – 1st pass: go 1-3 levels deep – Gather more requirements or data – Add more detail later Post-its on a wall
WBS Techniques Top-down – Start at highest level – Systematically develop increasing level of detail – Best if • The problem is well understood • Technology and methodology are not new • This is similar to an earlier project or problem – But is also applied in majority of situations
WBS Techniques Bottom-up – Start at lowest level tasks – Aggregate into summaries and higher levels – Cons • Time consuming • Needs more requirements complete – Pros • Detailed
WBS Techniques Analogy – Base WBS upon that of a “similar” project – Use a template – Analogy also can be estimation basis – Pros • Based on past actual experience – Cons • Needs comparable project
WBS Techniques Brainstorming – Generate all activities you can think of that need to be done – Group them into categories Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!)
WBS – Basis of Many Things Network scheduling Costing Risk analysis Organizational structure Control Measurement
WBS Guidelines Part 1 Should be easy to understand Some companies have corporate standards for these schemes Some top-level items, like Project Mgmt. are in WBS for each project – Others vary by project What often hurts most is what‟s missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable
WBS Guidelines Part 2 How detailed should it be? – Not as detailed as the final MS-Project plan – Each level should have no more than 7 items – It can evolve over time What tool should you use? – Excel, Word, Project – Org chart diagramming tool (Visio, etc) – Specialized commercial apps Re-use a “template” if you have one
Software Cost Estimation Determine size of the product. From the size estimate, – determine the effort needed. From the effort estimate, – determine project duration, and cost.
Financial Analysis of Projects Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects: – Net present value (NPV) analysis – Return on investment (ROI) – Payback analysis
Net Present Value Analysis: NPV NPV: a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better
NPV Example
Return on Investment (ROI) ROI: income divided by investment ROI = (total discounted benefits - total discounted costs) / discounted costs The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on investment for projects
Payback Analysis Another important financial consideration is payback analysis The “payback period” is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project Payback occurs when the cumulative discounted benefits and costs are greater than zero Many organizations want IT projects to have a fairly short payback period
NPV, ROI, Payback Period: Ex 1
NPV, ROI, Payback Period: Ex 2
Weighted Scoring Model A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria • First identify criteria important to the project selection process • Then assign weights (percentages) to each criterion so they add up to 100% • Then assign scores to each criterion for each project • Multiply scores * weights = total weighted scores The higher the weighted score, the better
Sample Weighted Scoring Model
Size Estimation Effort Estimation Cost Estimation Duration Estimation Staffing Estimation Scheduling Software Cost Estimation
Software Cost Estimation Three main approaches to estimation: –Empirical –Heuristic –Analytical
Software Cost Estimation Techniques Empirical techniques: – an educated guess based on past experience. Heuristic techniques: – assume that the characteristics to be estimated can be expressed in terms of some mathematical expression. Analytical techniques: – derive the required results starting from certain simple assumptions.
Software Size Metrics LOC (Lines of Code): – Simplest and most widely used metric. – Comments and blank lines should not be counted.
Disadvantages of Using LOC Size can vary with coding style. Focuses on coding activity alone. Correlates poorly with quality and efficiency of code. Penalizes higher level programming languages, code reuse, etc.
Disadvantages of Using LOC (cont...) Measures lexical/textual complexity only. – does not address the issues of structural or logical complexity. Difficult to estimate LOC from problem description. – So not useful for project planning
Function Point Metric Overcomes some of the shortcomings of the LOC metric Proposed by Albrecht in early 80's: – FP=4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces Input: – A set of related inputs is counted as one input.
Function Point Metric Output: – A set of related outputs is counted as one output. Inquiries: – Each user query type is counted. Files: – Files are logically related data and thus can be data structures or physical files. Interface: – Data transfer to other systems.
Function Point Metric(CONT.) Suffers from a major drawback: – the size of a function is considered to be independent of its complexity. Extend function point metric: – Feature Point metric: – considers an extra parameter: •Algorithm Complexity.
Function Point Metric(CONT.) Proponents claim: – FP is language independent. – Size can be easily derived from problem description Opponents claim: – it is subjective --- Different people can come up with different estimates for the same problem.
Empirical Size Estimation Techniques Expert Judgement: – An euphemism for guess made by an expert. – Suffers from individual bias. Delphi Estimation: – overcomes some of the problems of expert judgement.
Expert judgement Experts divide a software product into component units: – e.g. GUI, database module, data communication module, billing module, etc. Add up the guesses for each of the components.
Delphi Estimation: Team of Experts and a coordinator. Experts carry out estimation independently: – mention the rationale behind their estimation. – coordinator notes down any extraordinary rationale: •circulates among experts.
Delphi Estimation: Experts re-estimate. Experts never meet each other – to discuss their viewpoints.
Heuristic Estimation Techniques Single Variable Model: – Parameter to be Estimated=C1(Estimated Characteristic)d1 Multivariable Model: – Assumes that the parameter to be estimated depends on more than one characteristic. – Parameter to be Estimated=C1(Estimated Characteristic)d1+ C2(Estimated Characteristic)d2+… – Usually more accurate than single variable models.
COCOMO Model COCOMO (COnstructive COst MOdel) proposed by Boehm. Divides software product developments into 3 categories: – Organic – Semidetached – Embedded
COCOMO Product classes Roughly correspond to: – application, utility and system programs respectively. •Data processing and scientific programs are considered to be application programs. •Compilers, linkers, editors, etc., are utility programs. •Operating systems and real-time system programs, etc. are system programs.
Elaboration of Product classes Organic: – Relatively small groups • working to develop well-understood applications. Semidetached: – Project team consists of a mixture of experienced and inexperienced staff. Embedded: – The software is strongly coupled to complex hardware, or real-time systems.
COCOMO Model(CONT.) For each of the three product categories: – From size estimation (in KLOC), Boehm provides equations to predict: • project duration in months • effort in programmer-months Boehm obtained these equations: – examined historical data collected from a large number of actual projects.
COCOMO Model(CONT.) Software cost estimation is done through three stages: – Basic COCOMO, – Intermediate COCOMO, – Complete COCOMO.
Basic COCOMO Model(CONT.) Gives only an approximate estimation: – Effort = a1 (KLOC)a2 – Tdev = b1 (Effort)b2 • KLOC is the estimated kilo lines of source code, • a1,a2,b1,b2 are constants for different categories of software products, • Tdev is the estimated time to develop the software in months, • Effort estimation is obtained in terms of person months (PMs).
Development Effort Estimation Organic : – Effort = 2.4 (KLOC)1.05 PM Semi-detached: – Effort = 3.0(KLOC)1.12 PM Embedded: – Effort = 3.6 (KLOC)1.20PM
Development Time Estimation Organic: – Tdev = 2.5 (Effort)0.38 Months Semi-detached: – Tdev = 2.5 (Effort)0.35 Months Embedded: – Tdev = 2.5 (Effort)0.32 Months
Basic COCOMO Model(CONT.) Effort is somewhat super-linear in problem size. Effort Size
Basic COCOMO Model(CONT.) Development time – sublinear function of product size. When product size increases two times, – development time does not double. Time taken: – almost same for all the three product categories. Size Dev. Time 60K 18 Months 14 Months 30K
Basic COCOMO Model(CONT.) Development time does not increase linearly with product size: – For larger products more parallel activities can be identified: •can be carried out simultaneously by a number of engineers.
Basic COCOMO Model(CONT.) Development time is roughly the same for all the three categories of products: – For example, a 60 KLOC program can be developed in approximately 18 months • regardless of whether it is of organic, semi-detached, or embedded type. – There is more scope for parallel activities for system and application programs, • than utility programs.
Example The size of an organic software product has been estimated to be 32,000 lines of source code. Effort = 2.4*(32)1.05 = 91 PM Nominal development time = 2.5*(91)0.38 = 14 months
Intermediate COCOMO Basic COCOMO model assumes – effort and development time depend on product size alone. However, several parameters affect effort and development time: • Reliability requirements • Availability of CASE tools and modern facilities to the developers • Size of data to be handled
Intermediate COCOMO For accurate estimation, – the effect of all relevant parameters must be considered: – Intermediate COCOMO model recognizes this fact: •refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers).
Intermediate COCOMO(CONT.) If modern programming practices are used, – initial estimates are scaled downwards. If there are stringent reliability requirements on the product : – initial estimate is scaled upwards.
Intermediate COCOMO(CONT.) Rate different parameters on a scale of one to three: –Depending on these ratings, •multiply cost driver values with the estimate obtained using the basic COCOMO.
Intermediate COCOMO(CONT.) Cost driver classes: – Product: Inherent complexity of the product, reliability requirements of the product, etc. – Computer: Execution time, storage requirements, etc. – Personnel: Experience of personnel, etc. – Development Environment: Sophistication of the tools used for software development.
Shortcoming of basic and intermediate COCOMO models Both models: – consider a software product as a single homogeneous entity: – However, most large systems are made up of several smaller sub-systems. • Some sub-systems may be considered as organic type, some may be considered embedded, etc. • for some the reliability requirements may be high, and so on.
Complete COCOMO Cost of each sub-system is estimated separately. Costs of the sub-systems are added to obtain total cost. Reduces the margin of error in the final estimate.
Complete COCOMO Example A Management Information System (MIS) for an organization having offices at several places across the country: – Database part (semi-detached) – Graphical User Interface (GUI) part (organic) – Communication part (embedded) Costs of the components are estimated separately: – summed up to give the overall cost of the system.
Halstead's Software Science An analytical technique to estimate: – size, – development effort, – development time.
Halstead's Software Science Halstead used a few primitive program parameters – number of operators and operands Derived expressions for: – over all program length, – potential minimum volume • Potential volume (V*) – actual volume, – language level, • Program level (L) as L = V* /V – Effort(V/L), and – development time.
Example If the estimated development time is 1 year, then in order to develop the product in 6 months, – the total effort and hence the cost increases 16 times. – In other words, •the relationship between effort and the chronological delivery time is highly nonlinear.
Scheduling Once tasks (from the WBS) and size/effort (from estimation) are known: then schedule Primary objectives • Best time • Least cost • Least risk Secondary objectives • Evaluation of schedule alternatives • Effective use of resources • Communications
Terminology Precedence: • A task that must occur before another is said to have precedence of the other Concurrence: • Concurrent tasks are those that can occur at the same time (in parallel) Leads & Lag Time • Delays between activities • Time required before or after a given task
Terminology Milestones – Have a duration of zero – Identify critical points in your schedule – Shown as inverted triangle or a diamond – Often used at “review” or “delivery” times • Or at end or beginning of phases • Ex: Software Requirements Review (SRR) • Ex: User Sign-off – Can be tied to contract terms
Terminology Example Milestones
Terminology Slack & Float – Float & Slack: synonymous terms – Free Slack – Slack an activity has before it delays next task – Total Slack – Slack an activity has before delaying whole project – Slack Time TS = TL – TE • TE = earliest time an event can take place • TL = latest date it can occur w/o extending project‟s completion date
Scheduling Techniques – Mathematical Analysis • Network Diagrams – PERT – CPM – GERT – Bar Charts • Milestone Chart • Gantt Chart
Network Diagrams Developed in the 1950‟s A graphical representation of the tasks necessary to complete a project Visualizes the flow of tasks & relationships
Mathematical Analysis PERT – Program Evaluation and Review Technique CPM – Critical Path Method Sometimes treated synonymously All are models using network diagrams
MS-Project Example
Network Diagrams Two classic formats – AOA: Activity on Arrow – AON: Activity on Node Each task labeled with • Identifier (usually a letter/code) • Duration (in std. unit like days) There are other variations of labeling There is 1 start & 1 end event Time goes from left to right
Node Formats
Network Diagrams AOA consists of • Circles representing Events – Such as „start‟ or „end‟ of a given task • Lines representing Tasks – Thing being done „Build UI‟ • a.k.a. Arrow Diagramming Method (ADM) AON • Tasks on Nodes – Nodes can be circles or rectangles (usually latter) – Task information written on node • Arrows are dependencies between tasks • a.k.a. Precedence Diagramming Method (PDM)
Critical Path “The specific set of sequential tasks upon which the project completion date depends” – or “the longest full path” All projects have a Critical Path Accelerating non-critical tasks do not directly shorten the schedule
Critical Path Example
CPM Critical Path Method – The process for determining and optimizing the critical path Non-CP tasks can start earlier or later w/o impacting completion date Note: Critical Path may change to another as you shorten the current Should be done in conjunction with the you & the functional manager
4 Task Dependency Types Mandatory Dependencies • “Hard logic” dependencies • Nature of the work dictates an ordering • Ex: Coding has to precede testing • Ex: UI design precedes UI implementation Discretionary Dependencies • “Soft logic” dependencies • Determined by the project management team • Process-driven • Ex: Discretionary order of creating certain modules
4 Task Dependency Types External Dependencies • Outside of the project itself • Ex: Release of 3rd party product; contract signoff • Ex: stakeholders, suppliers, Y2K, year end Resource Dependencies • Two task rely on the same resource • Ex: You have only one DBA but multiple DB tasks
Task Dependency Relationships Finish-to-Start (FS) – B cannot start till A finishes – A: Construct fence; B: Paint Fence Start-to-Start (SS) – B cannot start till A starts – A: Pour foundation; B: Level concrete Finish-to-Finish (FF) – B cannot finish till A finishes – A: Add wiring; B: Inspect electrical Start-to-Finish (SF) – B cannot finish till A starts (rare)
Example Step 1
Forward Pass To determine early start (ES) and early finish (EF) times for each task Work from left to right Adding times in each path Rule: when several tasks converge, the ES for the next task is the largest of preceding EF times
Example Step 2
Backward Pass To determine the last finish (LF) and last start (LS) times Start at the end node Compute the bottom pair of numbers Subtract duration from connecting node‟s earliest start time
Example Step 3
Example Step 4
Slack & Reserve How can slack be negative? What does that mean? How can you address that situation?
Slack & Reserve Start Date Project Due Date Forward Pass A Backward Pass B Reserve Time Negative Slack
Network Diagrams Advantages – Show precedence well – Reveal interdependencies not shown in other techniques – Ability to calculate critical path – Ability to perform “what if” exercises Disadvantages – Default model assumes resources are unlimited • You need to incorporate this yourself (Resource Dependencies) when determining the “real” Critical Path – Difficult to follow on large projects
PERT Program Evaluation and Review Technique Based on idea that estimates are uncertain – Therefore uses duration ranges – And the probability of falling to a given range Uses an “expected value” (or weighted average) to determine durations Use the following methods to calculate the expected durations, then use as input to your network diagram
PERT Start with 3 estimates – Optimistic • Would likely occur 1 time in 20 – Most likely • Modal value of the distribution – Pessimistic • Would be exceeded only one time in 20
PERT Formula Combined to estimate a task duration
PERT Formula Confidence Interval can be determined Based on a standard deviation of the expected time • Using a bell curve (normal distribution) For the whole critical path use
PERT Example Confidence interval for P2 is 4 times wider than P1 for a given probability Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2) Description Planner 1 Planner 2 m 10d 10d a 9d 9d b 12d 20d PERT time 10.16d 11.5d Std. Dev. 0.5d 1.8d
PERT Advantages – Accounts for uncertainty Disadvantages – Time and labor intensive – Assumption of unlimited resources is big issue – Lack of functional ownership of estimates – Mostly only used on large, complex project Get PERT software to calculate it for you
CPM vs. PERT Both use Network Diagrams CPM: deterministic PERT: probabilistic CPM: one estimate, PERT, three estimates PERT is infrequently used
Milestone Chart Sometimes called a “bar charts” Simple Gantt chart – Either showing just highest summary bars – Or milestones only
Bar Chart
Gantt Chart
Gantt Chart Disadvantages – Does not show interdependencies well – Does not uncertainty of a given activity (as does PERT) Advantages – Easily understood – Easily created and maintained Note: Software now shows dependencies among tasks in Gantt charts – In the “old” days Gantt charts did not show these dependencies, bar charts typically do not
Reducing Project Duration How can you shorten the schedule? Via – Reducing scope (or quality) – Adding resources – Concurrency (perform tasks in parallel) – Substitution of activities
Compression Techniques Shorten the overall duration of the project Crashing • Looks at cost and schedule tradeoffs • Gain greatest compression with least cost • Add resources to critical path tasks • Limit or reduce requirements (scope) • Changing the sequence of tasks Fast Tracking • Overlapping of phases, activities or tasks that would otherwise be sequential • Involves some risk • May cause rework
Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur. – Project risks affect schedule or resources – Product risks affect the quality or performance of the software being developed – Business risks affect the organisation developing or procuring the software
The risk management process Risk identification – Identify project, product and business risks Risk analysis – Assess the likelihood and consequences of these risks Risk planning – Draw up plans to avoid or minimise the effects of the risk Risk monitoring – Monitor the risks throughout the project
Levels of Risk Management 1. Crisis Management - everything‟s broken 2. Fix on failure - something broke? Fix it! 3. Risk mitigation - what will we do when it breaks?
Levels of Risk Management 4. Prevention - how keep it from breaking? 5. Eliminate root causes - why could it break? PLEASE strive for the last two levels
Risk Assessment & Control Risk Assessment – Identification – what are the risks? Make a list! (Or borrow one for ideas) – Analysis – assess risk likelihood and impact; find possible alternatives – Prioritization – which risks to focus on? Sort risks by impact ...
Risk Assessment & Control Risk Control – Management planning – mitigation planning, ensure consistency among plans – Resolution – actively manage and resolve each risk when it occurs – Monitoring – track progress toward risk resolution; and identify new risks
Risk Identification Look for risks – In all of the major areas of the project - resources, tools, process, and product – In management areas - cost, schedule, level of effort – In the Classic Mistakes and Fundamentals – In every area your customer cares about!
Risk Identification Categories of schedule risks – Schedule creation – Organization and management – Development environment – End users – Customers – Contractors – ...
Risk Identification More schedule risks – Requirements – Product – External environment – Personnel – Design and implementation – Process
Risk Identification Risk identification has two different meanings: – Define what risks might occur (as previously described), and then analyze them – Be able to tell when a risk has taken place (which sets the stage for risk monitoring and mitigation)
Risks and risk types R is k t y p e P o s s ib le r is k s T e c h n o lo g y T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p r o c e s s a s m a n y tr a n s a c tio n s p e r s e c o n d a s e x p e c te d . S o ftw a r e c o m p o n e n ts w h ic h s h o u ld b e r e u s e d c o n ta in d e fe c ts w h ic h lim it th e ir fu n c tio n a lity . P e o p le It is im p o s s ib le to r e c r u it s ta ff w ith th e s k ills r e q u ir e d . K e y s ta ff a r e ill a n d u n a v a ila b le a t c r itic a l tim e s . R e q u ir e d tr a in in g fo r s ta ff is n o t a v a ila b le . O r g a n is a tio n a l T h e o r g a n is a tio n is r e s tr u c tu r e d s o th a t d iffe r e n t m a n a g e m e n t a r e r e s p o n s ib le fo r th e p r o je c t. O r g a n is a tio n a l fin a n c ia l p r o b le m s fo r c e r e d u c tio n s in th e p r o je c t b u d g e t. T o o ls T h e c o d e g e n e r a te d b y C A S E to o ls is in e ffic ie n t. C A S E to o ls c a n n o t b e in te g r a te d . R e q u ir e m e n ts C h a n g e s to r e q u ir e m e n ts w h ic h r e q u ir e m a jo r d e s ig n r e w o r k a r e p r o p o s e d . C u s to m e r s fa il to u n d e r s ta n d th e im p a c t o f r e q u ir e m e n ts c h a n g e s . E s tim a tio n T h e tim e r e q u ir e d to d e v e lo p th e s o ftw a r e is u n d e r e s tim a te d . T h e r a te o f d e fe c t r e p a ir is u n d e r e s tim a te d . T h e s iz e o f th e s o ftw a r e is u n d e r e s tim a te d .
Risk Analysis Risk Exposure (Impact) Calculation – Estimate Size of Loss; what is result of risk? – Estimate Probability of loss, based on corporate history, industry norms, or educated guesses – Multiply Size & Probability to get task Overrun due to that risk
Risk Analysis – Add task Overrun to the estimated task duration – Repeat for every significant risk
Risk analysis R is k P r o b a b ility E ffe c ts O rg a n is a tio n a l f in a n c ia l p ro b le m s f o rc e re d u c tio n s in th e p ro je c t b u d g e t. L o w C a ta s tro p h ic It is im p o s s ib le to re c ru it s ta f f w ith th e s k ills re q u ire d f o r th e p ro je c t. H ig h C a ta s tro p h ic K e y s ta f f a re ill a t c ritic a l tim e s in th e p ro je c t. M o d e ra te S e rio u s S o f tw a re c o m p o n e n ts w h ic h s h o u ld b e re u s e d c o n ta in d e f e c ts w h ic h lim it th e ir f u n c tio n a lity . M o d e ra te S e rio u s C h a n g e s to re q u ire m e n ts w h ic h re q u ire m a jo r d e s ig n re w o rk a re p ro p o s e d . M o d e ra te S e rio u s T h e o rg a n is a tio n is re s tru c tu re d s o th a t d if f e re n t m a n a g e m e n t a re re s p o n s ib le f o r th e p ro je c t. H ig h S e rio u s T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p ro c e s s a s m a n y tra n s a c tio n s p e r s e c o n d a s e x p e c te d . M o d e ra te S e rio u s T h e tim e re q u ire d to d e v e lo p th e s o f tw a re is u n d e re s tim a te d . H ig h S e rio u s C A S E to o ls c a n n o t b e in te g ra te d . H ig h T o le ra b le C u s to m e rs f a il to u n d e rs ta n d th e im p a c t o f re q u ire m e n ts c h a n g e s . M o d e ra te T o le ra b le R e q u ire d tra in in g f o r s ta f f is n o t a v a ila b le . M o d e ra te T o le ra b le T h e ra te o f d e f e c t re p a ir is u n d e re s tim a te d . M o d e ra te T o le ra b le T h e s iz e o f th e s o f tw a re is u n d e re s tim a te d . H ig h T o le ra b le T h e c o d e g e n e ra te d b y C A S E to o ls is in e f f ic ie n t. M o d e ra te In s ig n if ic a n t
Risk Exposure Calculation Suppose task 3.6, “Define requirements for GUI”, has an estimated duration of 30 days.
Risk Exposure Calculation If we know, based on historic data, that there is a 20% chance of this task running over by 10 days, the task overrun is 0.20*10 = 2 days. Hence in the schedule we should allow 30 + 2 = 32 days for this task, not just 30.
Risk Prioritization Sort risks by descending task overrun This will automatically identify risks with the highest task overrun Focus on those risks most, since you have the most to lose if you don‟t!
Risk Control Risk Management Planning Risk Resolution Risk Monitoring
Risk Management Planning For each risk, identify how risk is to be identified, managed, monitored, and closed out. Consider: – What is the risk, – Where and When might the risk occur, – Who is responsible for managing that risk, – Why does the risk exist, and – How will the risk be handled if it occurs?
Risk Management Planning Similar to security analysis: – Identify threats – Prevent threats – Detect threats (not trivial with information systems!) – Mitigate (reduce) the effects of the threats
Risk Resolution Avoid the risk (have someone else do it) Transfer risk to another area (e.g. redesign) Investigate the risk to better understand it (e.g. use prototype or consultant to clarify) Eliminate the cause of the risk (defect prevention) ...
Risk Resolution Assume the risk will occur and cope with minor impact Publicize the risk - well known risks are easier to avoid, and less shocking if they do occur Control the risk - implement mitigation strategy Remember the risk - keep lessons learned!
Risk Monitoring Develop and maintain top 10 risk list Conduct postmortems after each major project event (milestone) - collect and record lessons learned Assign a risk officer - a devil‟s advocate, if you will - to keep pestering with “what if...” situations Don‟t be afraid to discuss risks openly
Top 10 Risks List Develop a list of the ten most serious risks, their status, and mitigation plans Review and update each week Raises awareness of risks, and helps detect (identify) them
Risk Management Tasks Develop Risk Management Plan – May take from one week to several months, depending on project size – Results in approval of Risk Management Plan
Risk Management Tasks Update Risk List at a weekly status meeting – Update existing risks, add new ones as needed Reevaluate Risk Management Plan every 3 months to year, depending on project size
Risk Management Tasks Be sure to account for the following ongoing risk management activities: – Risk identification (what could happen?) – Risk management planning • Risk analysis and prioritization (what would result?) – Risk resolution (mitigation strategy) – Risk monitoring (has it happened?)
Risk Management Tasks For each risk, describe: – Risk number, name, and description – The Loss Hours, Probability, and Impact of each risk; sorted by descending Impact – How each risk will be: prevented (keep it from happening), identified (know when it has happened), and mitigated (managed once it has happened)
Impact of Software Review and Inspection
Content Software Development Process Informal Review Software Inspection Process Performed Software Inspections Results Experience Conclusions and Future
SW Development Process identify needs & common issues, define priorities and work-plan, define components perform pre-design investigations -> identify candidate technologies/techniques develop high-level design refine design, implement code 180,000 lines of C++ 40 % generated unit test components integrate with other subsystems Total 800 000 lines incl. external sw Collect Requirements Pre-design Investigations High-level Design Testing & Integration Detailed Design Implementation Training, Programming and Testing Tools, FrameMaker, html, SRT Configuration Management, StP/OMT CASE TOOLS Software Development Environment
Review - Inspection Review: • Presentation of each SW Component to the Group in each Development Phase • Discussion and Coordination with other components • Goal: Clarification and Accept/Reject Decision Inspection: • Quality Improvement Process to the software project • Goal: Defect Detection & Defect Prevention
Informal Review From the start of the project – document preparation and monthly open meetings • present status, results, proposals • inform colleagues - receive feedback • suggestions -> enhancements -> acceptance Results: – Coherent set of end-product components – Increased communication Drawback: – Lack of time of reviewers – No code review
Inspection in the SDP Document Inspection Document Inspection Document Inspection Code Inspection Document Inspection Applying Testing Tools Code Inspection Requirements Design Test ImplementationImplementation Test Test Plan
Inspection - Objectives Defect Detection – documents are checked for cleanness and consistency against rules Defect Prevention – learning from defects found – suggesting improvements On the Job Training – education in standards and rules – apply creativity
Sources Inspection Process Map Planning & Entry Kick-off Meeting Checking Logging Meeting Brainstorming Edit Exit Follow-up Inspection Plan Issue log tables Action Lists Exit Product Data Summary Change Requests Product Rules Checklists
List of performed Inspections Requirement Inspection • DS - Diagnostic System • IGUI - Integrated Graphical User Interface • DAL - Data Access Library Design Inspection • TM - Test Manager • DS - Diagnostic System Code Inspection • IPC - Inter Process Communication • MRS - Message Reporting System • IS - Information Service • DAL - Data Access Library 180 pages of documents 8000 lines of code
Results: Issue log table Each issue is logged, discussed, checked Emphasis on non-trivial issues Per Inspection : 10 to 200 issues found Number of recorded issue logs depend on: • Type of Inspection • Phase of Project • Entry conditions • Experience of Inspectors • Counting system -> Improved Code -> Improved Documentation
Inspection Process Results Change Requests – To Rules for Requirements, Design or Coding use of ’shall’ ’should’ ’may’ for Requirements adopt standard command line parameters use of coding conventions program exit status convention – To the Inspection Procedure Suggestions about editor comment types possible strategy on rule checking Action Lists – Actions to be performed outside the Inspection Process – Questions to be clarified, i.e. beyond the scope of Inspection
Observations Requirements • most important, the first in the chain: • a bug may propagate to the end -> unwanted results even with perfect code Design • the hardest to inspect • difficult to provide a good set of guidelines Code • most time consuming: Code & Documentation, mother documents & reference documents • Good set of rules, Use of automatic checking tools
Adaptation to Environment Everything is allowed • which helps improving – process – product – communication – cooperation, education – integration, coherence while keeping Consistency • improving Efficiency HEP: geographically distributed no specialized expertise little formal training little hierarchical power participation by conviction
Efficiency - Flexibility Efficiency • Inspection is time consuming • - don‟t waste time and effort of inspectors • Careful planning and Clear Instructions • Solid Process Framework • Inspect Samples • Motivation of peers Flexibility • Build in change Management • Well defined procedure • - but each inspection to be handled individually
Experience Inspection is Take fears seriously Explain aims Respect privacy Demonstrate helpfulness Participation Trust amongst colleagues Constructive criticism Integration Common working culture Fear to be criticized and judged
Conclusions Reviews prepare the ground and stabilize SDP Adaptation of the inspection method for the Environment Gain in quality and experience Appreciated by authors and peers Help for team building in a distributed environment
Future Good understanding for the next phase: – stabilize inspection process and keep style – provide a helpful framework based on experience – use it through entire development cycle – „lighter‟ inspection - faster turnaround time – use sampling techniques – keep real logging meetings where possible – provide metrics – stay flexible and efficient
Closing Process Administrative Closure Contract Close-out Formalizing acceptance of the project or phase and bringing it to an orderly end
Thank You

Recommended

hci in software development process
hci in software development processhci in software development process
hci in software development process
Kainat Ilyas
 
Introduction to Software Project Management
Introduction to Software Project ManagementIntroduction to Software Project Management
Introduction to Software Project Management
Reetesh Gupta
 
software Prototyping model
software Prototyping modelsoftware Prototyping model
software Prototyping model
SankeerthanaS1
 
Unit 4
Unit 4Unit 4
Unit 4
Ravi Kumar
 
Mg6088 spm unit-2
Mg6088 spm unit-2Mg6088 spm unit-2
Mg6088 spm unit-2
SIMONTHOMAS S
 
Domain object model
Domain object modelDomain object model
Domain object model
university of education,Lahore
 
Intro (Distributed computing)
Intro (Distributed computing)Intro (Distributed computing)
Intro (Distributed computing)Sri Prasanna
 
Cluster computing
Cluster computingCluster computing
Cluster computing
Raja' Masa'deh
 

Recommended

hci in software development process
hci in software development processhci in software development process
hci in software development process
Kainat Ilyas
 
Introduction to Software Project Management
Introduction to Software Project ManagementIntroduction to Software Project Management
Introduction to Software Project Management
Reetesh Gupta
 
software Prototyping model
software Prototyping modelsoftware Prototyping model
software Prototyping model
SankeerthanaS1
 
Unit 4
Unit 4Unit 4
Unit 4
Ravi Kumar
 
Mg6088 spm unit-2
Mg6088 spm unit-2Mg6088 spm unit-2
Mg6088 spm unit-2
SIMONTHOMAS S
 
Domain object model
Domain object modelDomain object model
Domain object model
university of education,Lahore
 
Intro (Distributed computing)
Intro (Distributed computing)Intro (Distributed computing)
Intro (Distributed computing)Sri Prasanna
 
Cluster computing
Cluster computingCluster computing
Cluster computing
Raja' Masa'deh
 
Question answering
Question answeringQuestion answering
Question answering
Nafiseh Navabpour
 
Software project management- Software Engineering
Software project management- Software EngineeringSoftware project management- Software Engineering
Software project management- Software Engineering
Muhammad Yousuf Abdul Qadir
 
Software design
Software designSoftware design
Software designSyed Muhammad Hammad-ud-Din
 
Multiprocessor Systems
Multiprocessor SystemsMultiprocessor Systems
Multiprocessor Systems
vampugani
 
Lecture 3 threads
Lecture 3 threadsLecture 3 threads
Lecture 3 threads
Kumbirai Junior Muzavazi
 
Human Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdfHuman Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdf
vijaykumarK44
 
Software cost estimation techniques presentation
Software cost estimation techniques presentationSoftware cost estimation techniques presentation
Software cost estimation techniques presentation
Kudzai Rerayi
 
Software Reengineering
Software ReengineeringSoftware Reengineering
Software Reengineering
Deniz Kılınç
 
Software Project Management
Software Project ManagementSoftware Project Management
Software Project Management
Ramesh Babu
 
software project management
software project managementsoftware project management
software project management
Varendra University Rajshahi-bangladesh
 
Project management 02112009
Project management 02112009Project management 02112009
Project management 02112009
Manish Chaurasia
 
Case tools
Case tools Case tools
Case tools
Sutha Vincent
 
Software Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project ManagementSoftware Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project Management
Ahsan Rahim
 
Chapter 1 1 - intro ppt
Chapter 1 1 - intro pptChapter 1 1 - intro ppt
Chapter 1 1 - intro ppt
NancyBeaulah_R
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
udaya khanal
 
Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23
Mohammed Romi
 
Distributed computing time
Distributed computing timeDistributed computing time
Distributed computing time
Deepak John
 
Lecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptxLecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptx
ironman427662
 
Operating system support in distributed system
Operating system support in distributed systemOperating system support in distributed system
Operating system support in distributed system
ishapadhy
 
Resource management
Resource managementResource management
Resource management
Dr Sandeep Kumar Poonia
 
Applying both of waterfall and iterative development
Applying both of waterfall and iterative developmentApplying both of waterfall and iterative development
Applying both of waterfall and iterative development
Deny Prasetia
 
Process models
Process modelsProcess models
Process models
Preeti Mishra
 

More Related Content

What's hot

Question answering
Question answeringQuestion answering
Question answering
Nafiseh Navabpour
 
Software project management- Software Engineering
Software project management- Software EngineeringSoftware project management- Software Engineering
Software project management- Software Engineering
Muhammad Yousuf Abdul Qadir
 
Multiprocessor Systems
Multiprocessor SystemsMultiprocessor Systems
Multiprocessor Systems
vampugani
 
Lecture 3 threads
Lecture 3 threadsLecture 3 threads
Lecture 3 threads
Kumbirai Junior Muzavazi
 
Human Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdfHuman Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdf
vijaykumarK44
 
Software cost estimation techniques presentation
Software cost estimation techniques presentationSoftware cost estimation techniques presentation
Software cost estimation techniques presentation
Kudzai Rerayi
 
Software Reengineering
Software ReengineeringSoftware Reengineering
Software Reengineering
Deniz Kılınç
 
Software Project Management
Software Project ManagementSoftware Project Management
Software Project Management
Ramesh Babu
 
software project management
software project managementsoftware project management
software project management
Varendra University Rajshahi-bangladesh
 
Project management 02112009
Project management 02112009Project management 02112009
Project management 02112009
Manish Chaurasia
 
Case tools
Case tools Case tools
Case tools
Sutha Vincent
 
Software Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project ManagementSoftware Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project Management
Ahsan Rahim
 
Chapter 1 1 - intro ppt
Chapter 1 1 - intro pptChapter 1 1 - intro ppt
Chapter 1 1 - intro ppt
NancyBeaulah_R
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
udaya khanal
 
Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23
Mohammed Romi
 
Distributed computing time
Distributed computing timeDistributed computing time
Distributed computing time
Deepak John
 
Lecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptxLecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptx
ironman427662
 
Operating system support in distributed system
Operating system support in distributed systemOperating system support in distributed system
Operating system support in distributed system
ishapadhy
 
Resource management
Resource managementResource management
Resource management
Dr Sandeep Kumar Poonia
 

What's hot (20)

Question answering
Question answeringQuestion answering
Question answering
 
Software project management- Software Engineering
Software project management- Software EngineeringSoftware project management- Software Engineering
Software project management- Software Engineering
 
Software design
Software designSoftware design
Software design
 
Multiprocessor Systems
Multiprocessor SystemsMultiprocessor Systems
Multiprocessor Systems
 
Lecture 3 threads
Lecture 3 threadsLecture 3 threads
Lecture 3 threads
 
Human Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdfHuman Computer Interaction Notes 176.pdf
Human Computer Interaction Notes 176.pdf
 
Software cost estimation techniques presentation
Software cost estimation techniques presentationSoftware cost estimation techniques presentation
Software cost estimation techniques presentation
 
Software Reengineering
Software ReengineeringSoftware Reengineering
Software Reengineering
 
Software Project Management
Software Project ManagementSoftware Project Management
Software Project Management
 
software project management
software project managementsoftware project management
software project management
 
Project management 02112009
Project management 02112009Project management 02112009
Project management 02112009
 
Case tools
Case tools Case tools
Case tools
 
Software Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project ManagementSoftware Project Management | An Overview of the Software Project Management
Software Project Management | An Overview of the Software Project Management
 
Chapter 1 1 - intro ppt
Chapter 1 1 - intro pptChapter 1 1 - intro ppt
Chapter 1 1 - intro ppt
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
 
Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23Ian Sommerville, Software Engineering, 9th Edition Ch 23
Ian Sommerville, Software Engineering, 9th Edition Ch 23
 
Distributed computing time
Distributed computing timeDistributed computing time
Distributed computing time
 
Lecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptxLecture 8 (software Metrics) Unit 3.pptx
Lecture 8 (software Metrics) Unit 3.pptx
 
Operating system support in distributed system
Operating system support in distributed systemOperating system support in distributed system
Operating system support in distributed system
 
Resource management
Resource managementResource management
Resource management
 

Similar to SOFTWARE ENGINEERING

Applying both of waterfall and iterative development
Applying both of waterfall and iterative developmentApplying both of waterfall and iterative development
Applying both of waterfall and iterative development
Deny Prasetia
 
Process models
Process modelsProcess models
Process models
Preeti Mishra
 
Software Project management
Software Project managementSoftware Project management
Software Project management
sameer farooq
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
Atul Karmyal
 
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
BinNguynVn3
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPM
Mubashir Ali
 
UNIT V - 1 SPM.pptx
UNIT V - 1 SPM.pptxUNIT V - 1 SPM.pptx
UNIT V - 1 SPM.pptx
Devnath13
 
Software process models
Software process modelsSoftware process models
Software process models
Malik WaQas
 
Chapter 1,2,3,4 notes
Chapter 1,2,3,4 notesChapter 1,2,3,4 notes
Chapter 1,2,3,4 notes
Aruna M
 
what-is-devops.ppt
what-is-devops.pptwhat-is-devops.ppt
what-is-devops.ppt
MohammadSamiuddin10
 
Proj Mgmt.ppt
Proj Mgmt.pptProj Mgmt.ppt
Proj Mgmt.ppt
NikhilDudka
 
Project management chapter_04 for MSBTE
Project management chapter_04 for MSBTEProject management chapter_04 for MSBTE
Project management chapter_04 for MSBTE
Kalyan Ingole
 
Chapter 2
Chapter 2 Chapter 2
Chapter 2
KaiEnTee1
 
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
loloka1
 
04. Project Management
04. Project Management04. Project Management
04. Project Management
BhuWan Khadka
 
Phases in Agile Development- 9.pptx
Phases in Agile Development- 9.pptxPhases in Agile Development- 9.pptx
Phases in Agile Development- 9.pptx
AlishaFida1
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
Rody Middelkoop
 
Fundamentals of Software Engineering
Fundamentals of Software Engineering Fundamentals of Software Engineering
Fundamentals of Software Engineering
Madhar Khan Pathan
 
Software vjhghjjkhjkkkghhjhEngineering.pdf
Software vjhghjjkhjkkkghhjhEngineering.pdfSoftware vjhghjjkhjkkkghhjhEngineering.pdf
Software vjhghjjkhjkkkghhjhEngineering.pdf
avishekpradhan24
 
Software engineering jwfiles 3
Software engineering jwfiles 3Software engineering jwfiles 3
Software engineering jwfiles 3
Azhar Shaik
 

Similar to SOFTWARE ENGINEERING (20)

Applying both of waterfall and iterative development
Applying both of waterfall and iterative developmentApplying both of waterfall and iterative development
Applying both of waterfall and iterative development
 
Process models
Process modelsProcess models
Process models
 
Software Project management
Software Project managementSoftware Project management
Software Project management
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
0121_RESOURCE_SoftwareDevelopmentLifecycles.pdf
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPM
 
UNIT V - 1 SPM.pptx
UNIT V - 1 SPM.pptxUNIT V - 1 SPM.pptx
UNIT V - 1 SPM.pptx
 
Software process models
Software process modelsSoftware process models
Software process models
 
Chapter 1,2,3,4 notes
Chapter 1,2,3,4 notesChapter 1,2,3,4 notes
Chapter 1,2,3,4 notes
 
what-is-devops.ppt
what-is-devops.pptwhat-is-devops.ppt
what-is-devops.ppt
 
Proj Mgmt.ppt
Proj Mgmt.pptProj Mgmt.ppt
Proj Mgmt.ppt
 
Project management chapter_04 for MSBTE
Project management chapter_04 for MSBTEProject management chapter_04 for MSBTE
Project management chapter_04 for MSBTE
 
Chapter 2
Chapter 2 Chapter 2
Chapter 2
 
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models.ppt
 
04. Project Management
04. Project Management04. Project Management
04. Project Management
 
Phases in Agile Development- 9.pptx
Phases in Agile Development- 9.pptxPhases in Agile Development- 9.pptx
Phases in Agile Development- 9.pptx
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Fundamentals of Software Engineering
Fundamentals of Software Engineering Fundamentals of Software Engineering
Fundamentals of Software Engineering
 
Software vjhghjjkhjkkkghhjhEngineering.pdf
Software vjhghjjkhjkkkghhjhEngineering.pdfSoftware vjhghjjkhjkkkghhjhEngineering.pdf
Software vjhghjjkhjkkkghhjhEngineering.pdf
 
Software engineering jwfiles 3
Software engineering jwfiles 3Software engineering jwfiles 3
Software engineering jwfiles 3
 

More from Gaditek

Digital marketing strategy and planning | About Business
Digital marketing strategy and planning | About BusinessDigital marketing strategy and planning | About Business
Digital marketing strategy and planning | About Business
Gaditek
 
Intro to social network analysis | What is Network Analysis? | History of (So...
Intro to social network analysis | What is Network Analysis? | History of (So...Intro to social network analysis | What is Network Analysis? | History of (So...
Intro to social network analysis | What is Network Analysis? | History of (So...
Gaditek
 
Marketing ethics and social responsibility | Criticisms of Marketing
Marketing ethics and social responsibility | Criticisms of MarketingMarketing ethics and social responsibility | Criticisms of Marketing
Marketing ethics and social responsibility | Criticisms of Marketing
Gaditek
 
understanding and capturing customer value | What Is a Price?
understanding and capturing customer value | What Is a Price?understanding and capturing customer value | What Is a Price?
understanding and capturing customer value | What Is a Price?
Gaditek
 
The marketing environment | Suppliers | Marketing intermediaries
The marketing environment | Suppliers | Marketing intermediariesThe marketing environment | Suppliers | Marketing intermediaries
The marketing environment | Suppliers | Marketing intermediaries
Gaditek
 
strategic planning | Customer Relationships | Partnering to Build
strategic planning | Customer Relationships | Partnering to Build strategic planning | Customer Relationships | Partnering to Build
strategic planning | Customer Relationships | Partnering to Build
Gaditek
 
Digital marketing | what is marketing?
Digital marketing | what is marketing?Digital marketing | what is marketing?
Digital marketing | what is marketing?
Gaditek
 
Fundamentals of Computer Design including performance measurements & quantita...
Fundamentals of Computer Design including performance measurements & quantita...Fundamentals of Computer Design including performance measurements & quantita...
Fundamentals of Computer Design including performance measurements & quantita...
Gaditek
 
Dealing with exceptions Computer Architecture part 2
Dealing with exceptions Computer Architecture part 2Dealing with exceptions Computer Architecture part 2
Dealing with exceptions Computer Architecture part 2
Gaditek
 
Dealing with Exceptions Computer Architecture part 1
Dealing with Exceptions Computer Architecture part 1Dealing with Exceptions Computer Architecture part 1
Dealing with Exceptions Computer Architecture part 1
Gaditek
 
Pipelining of Processors
Pipelining of ProcessorsPipelining of Processors
Pipelining of Processors
Gaditek
 
Instruction Set Architecture (ISA)
Instruction Set Architecture (ISA)Instruction Set Architecture (ISA)
Instruction Set Architecture (ISA)
Gaditek
 
differential equation Lecture#14
differential equation Lecture#14differential equation Lecture#14
differential equation Lecture#14
Gaditek
 
differential equation Lecture#12
differential equation Lecture#12differential equation Lecture#12
differential equation Lecture#12
Gaditek
 
differential equation Lecture#11
differential equation Lecture#11differential equation Lecture#11
differential equation Lecture#11
Gaditek
 
differential equation Lecture#13
differential equation Lecture#13differential equation Lecture#13
differential equation Lecture#13
Gaditek
 
differential equation Lecture#10
differential equation Lecture#10differential equation Lecture#10
differential equation Lecture#10
Gaditek
 
differential equation Lecture#9
differential equation Lecture#9differential equation Lecture#9
differential equation Lecture#9
Gaditek
 
differential equation Lecture#8
differential equation Lecture#8differential equation Lecture#8
differential equation Lecture#8
Gaditek
 
differential equation Lecture#7
differential equation Lecture#7differential equation Lecture#7
differential equation Lecture#7
Gaditek
 

More from Gaditek (20)

Digital marketing strategy and planning | About Business
Digital marketing strategy and planning | About BusinessDigital marketing strategy and planning | About Business
Digital marketing strategy and planning | About Business
 
Intro to social network analysis | What is Network Analysis? | History of (So...
Intro to social network analysis | What is Network Analysis? | History of (So...Intro to social network analysis | What is Network Analysis? | History of (So...
Intro to social network analysis | What is Network Analysis? | History of (So...
 
Marketing ethics and social responsibility | Criticisms of Marketing
Marketing ethics and social responsibility | Criticisms of MarketingMarketing ethics and social responsibility | Criticisms of Marketing
Marketing ethics and social responsibility | Criticisms of Marketing
 
understanding and capturing customer value | What Is a Price?
understanding and capturing customer value | What Is a Price?understanding and capturing customer value | What Is a Price?
understanding and capturing customer value | What Is a Price?
 
The marketing environment | Suppliers | Marketing intermediaries
The marketing environment | Suppliers | Marketing intermediariesThe marketing environment | Suppliers | Marketing intermediaries
The marketing environment | Suppliers | Marketing intermediaries
 
strategic planning | Customer Relationships | Partnering to Build
strategic planning | Customer Relationships | Partnering to Build strategic planning | Customer Relationships | Partnering to Build
strategic planning | Customer Relationships | Partnering to Build
 
Digital marketing | what is marketing?
Digital marketing | what is marketing?Digital marketing | what is marketing?
Digital marketing | what is marketing?
 
Fundamentals of Computer Design including performance measurements & quantita...
Fundamentals of Computer Design including performance measurements & quantita...Fundamentals of Computer Design including performance measurements & quantita...
Fundamentals of Computer Design including performance measurements & quantita...
 
Dealing with exceptions Computer Architecture part 2
Dealing with exceptions Computer Architecture part 2Dealing with exceptions Computer Architecture part 2
Dealing with exceptions Computer Architecture part 2
 
Dealing with Exceptions Computer Architecture part 1
Dealing with Exceptions Computer Architecture part 1Dealing with Exceptions Computer Architecture part 1
Dealing with Exceptions Computer Architecture part 1
 
Pipelining of Processors
Pipelining of ProcessorsPipelining of Processors
Pipelining of Processors
 
Instruction Set Architecture (ISA)
Instruction Set Architecture (ISA)Instruction Set Architecture (ISA)
Instruction Set Architecture (ISA)
 
differential equation Lecture#14
differential equation Lecture#14differential equation Lecture#14
differential equation Lecture#14
 
differential equation Lecture#12
differential equation Lecture#12differential equation Lecture#12
differential equation Lecture#12
 
differential equation Lecture#11
differential equation Lecture#11differential equation Lecture#11
differential equation Lecture#11
 
differential equation Lecture#13
differential equation Lecture#13differential equation Lecture#13
differential equation Lecture#13
 
differential equation Lecture#10
differential equation Lecture#10differential equation Lecture#10
differential equation Lecture#10
 
differential equation Lecture#9
differential equation Lecture#9differential equation Lecture#9
differential equation Lecture#9
 
differential equation Lecture#8
differential equation Lecture#8differential equation Lecture#8
differential equation Lecture#8
 
differential equation Lecture#7
differential equation Lecture#7differential equation Lecture#7
differential equation Lecture#7
 

Recently uploaded

Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxTop Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
rickgrimesss22
 
Large Language Models and the End of Programming
Large Language Models and the End of ProgrammingLarge Language Models and the End of Programming
Large Language Models and the End of Programming
Matt Welsh
 
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
informapgpstrackings
 
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamOpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
takuyayamamoto1800
 
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
Juraj Vysvader
 
Navigating the Metaverse: A Journey into Virtual Evolution"
Navigating the Metaverse: A Journey into Virtual Evolution"Navigating the Metaverse: A Journey into Virtual Evolution"
Navigating the Metaverse: A Journey into Virtual Evolution"
Donna Lenk
 
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteAI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
Google
 
top nidhi software solution freedownload
top nidhi software solution freedownloadtop nidhi software solution freedownload
top nidhi software solution freedownload
vrstrong314
 
Graphic Design Crash Course for beginners
Graphic Design Crash Course for beginnersGraphic Design Crash Course for beginners
Graphic Design Crash Course for beginners
e20449
 
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
Mind IT Systems
 
Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
Fermin Galan
 
Using IESVE for Room Loads Analysis - Australia & New Zealand
Using IESVE for Room Loads Analysis - Australia & New ZealandUsing IESVE for Room Loads Analysis - Australia & New Zealand
Using IESVE for Room Loads Analysis - Australia & New Zealand
IES VE
 
Lecture 1 Introduction to games development
Lecture 1 Introduction to games developmentLecture 1 Introduction to games development
Lecture 1 Introduction to games development
abdulrafaychaudhry
 
A Comprehensive Look at Generative AI in Retail App Testing.pdf
A Comprehensive Look at Generative AI in Retail App Testing.pdfA Comprehensive Look at Generative AI in Retail App Testing.pdf
A Comprehensive Look at Generative AI in Retail App Testing.pdf
kalichargn70th171
 
SOCRadar Research Team: Latest Activities of IntelBroker
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar Research Team: Latest Activities of IntelBroker
SOCRadar Research Team: Latest Activities of IntelBroker
SOCRadar
 
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, BetterWebinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
XfilesPro
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
Philip Schwarz
 
Globus Compute wth IRI Workflows - GlobusWorld 2024
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus Compute wth IRI Workflows - GlobusWorld 2024
Globus Compute wth IRI Workflows - GlobusWorld 2024
Globus
 
First Steps with Globus Compute Multi-User Endpoints
First Steps with Globus Compute Multi-User EndpointsFirst Steps with Globus Compute Multi-User Endpoints
First Steps with Globus Compute Multi-User Endpoints
Globus
 
GlobusWorld 2024 Opening Keynote session
GlobusWorld 2024 Opening Keynote sessionGlobusWorld 2024 Opening Keynote session
GlobusWorld 2024 Opening Keynote session
Globus
 

Recently uploaded (20)

Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxTop Features to Include in Your Winzo Clone App for Business Growth (4).pptx
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptx
 
Large Language Models and the End of Programming
Large Language Models and the End of ProgrammingLarge Language Models and the End of Programming
Large Language Models and the End of Programming
 
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...
 
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamOpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam
 
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...
 
Navigating the Metaverse: A Journey into Virtual Evolution"
Navigating the Metaverse: A Journey into Virtual Evolution"Navigating the Metaverse: A Journey into Virtual Evolution"
Navigating the Metaverse: A Journey into Virtual Evolution"
 
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteAI Pilot Review: The World’s First Virtual Assistant Marketing Suite
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
 
top nidhi software solution freedownload
top nidhi software solution freedownloadtop nidhi software solution freedownload
top nidhi software solution freedownload
 
Graphic Design Crash Course for beginners
Graphic Design Crash Course for beginnersGraphic Design Crash Course for beginners
Graphic Design Crash Course for beginners
 
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...
 
Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
 
Using IESVE for Room Loads Analysis - Australia & New Zealand
Using IESVE for Room Loads Analysis - Australia & New ZealandUsing IESVE for Room Loads Analysis - Australia & New Zealand
Using IESVE for Room Loads Analysis - Australia & New Zealand
 
Lecture 1 Introduction to games development
Lecture 1 Introduction to games developmentLecture 1 Introduction to games development
Lecture 1 Introduction to games development
 
A Comprehensive Look at Generative AI in Retail App Testing.pdf
A Comprehensive Look at Generative AI in Retail App Testing.pdfA Comprehensive Look at Generative AI in Retail App Testing.pdf
A Comprehensive Look at Generative AI in Retail App Testing.pdf
 
SOCRadar Research Team: Latest Activities of IntelBroker
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar Research Team: Latest Activities of IntelBroker
SOCRadar Research Team: Latest Activities of IntelBroker
 
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, BetterWebinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
Webinar: Salesforce Document Management 2.0 - Smarter, Faster, Better
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
 
Globus Compute wth IRI Workflows - GlobusWorld 2024
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus Compute wth IRI Workflows - GlobusWorld 2024
Globus Compute wth IRI Workflows - GlobusWorld 2024
 
First Steps with Globus Compute Multi-User Endpoints
First Steps with Globus Compute Multi-User EndpointsFirst Steps with Globus Compute Multi-User Endpoints
First Steps with Globus Compute Multi-User Endpoints
 
GlobusWorld 2024 Opening Keynote session
GlobusWorld 2024 Opening Keynote sessionGlobusWorld 2024 Opening Keynote session
GlobusWorld 2024 Opening Keynote session
 

SOFTWARE ENGINEERING

  • 1. Course Title: Software Engineering I Prerequisites: Object Oriented Language Degree: BSC [ Bachelor of Computer Science ] Duration: 18 weeks in Seven semester Lectures: 48 in total, 3 per week, including some examples. Laboratories: none
  • 2. Introduction to Software Project Management Software Management Project Set of instruction with well define date structure & Algorithms A Specific plan or design or planned activity. The act of managing something
  • 3. Characteristics of Software Project : • Non routine tasks are involved. • Planning is required. • The project has a pre-determined time span. • Work is carried out for someone other than yourself Software Project: A Specific plan or design or planned activity.
  • 4. Characteristics of Software Project : • Work involves several specialists. • Work is carried out in several phases. • The project is large or complex. • The resources that are available for use on the project are constrained. • Specific object are to be met or a specified product is o be created.
  • 5. Software Projects Versus other types of Project Software Project Essence Invisibility Conformity Flexibility/Changeability Complexity Project Visible Inflexible Complexity
  • 6. What is Management? Planning: deciding what is to be done. Organizing: making arrangements Staffing: Selecting the right people for the job. Directing: giving instructions. Monitoring: Checking on progress. Controlling: taking action to remedy hold-ups. Innovation: coming up with new solutions. Representing: liaising with users.
  • 8. Software Development and Project Management: Issues and Global Standards • Not only writing Code ? • Careful Analysis of Requirements • Fitting Requirements in Documentation Template • Design based on time frame and costing • Quality Assurance • Standard Testing • Maintenance
  • 9. Introduction to Software Project Management Goals – Software delivered within budget – Software delivered within schedule – Software is built according to requirements Why? – Well-managed projects sometimes fail – Badly managed projects inevitably fail – Software development process is not standardized
  • 10. Main causes of software failures Customer needs are misunderstood or not fully captured; Customer requirements change too frequently; Customers are not prepared to commit sufficient resources to the project; Customers do not want to cooperate with developers; Customers have unrealistic expectations; The system is no longer in benefit to customers; The developers may not be up to the task.
  • 11. Why Do Projects Succeed? How to identify a projects success potential – What metrics could you look at? • Project size • Project duration • Project team size • Executive support • User involvement • Experience project manager • Clear business objectives • Minimized scope • Standard software infrastructure • Firm basic requirements • Formal methodology • Reliable estimates
  • 12. Why Executive Support? Top management can help to: – Secure adequate resources – Get approval for unique project needs in a timely manner – Receive cooperation from people throughout the organization – Provide leadership guidance
  • 13. Project Manager Responsibilities • Proposal Writing • Project Costing • Project Planning & Scheduling • Project Monitoring & Reviews • Personnel Selection & Evaluation • Report Writing & Presentations
  • 14. – Understand the four P‟s: • People – must be organized to work effectively • Product – must have effective communication with the customer to specify scope and requirements • Process – must be appropriate for people and product • Project – must estimate effort and time needed, define work products, establish quality checkpoints, establish methods to monitor and control work defined by plan
  • 15. The software accidents Stakeholders Process Modeling language and tools Stakeholders Two groups Customers Users System owners Developers Analysts Designers Programmers, etc.
  • 16. Process Process for: Order of activities Product delivery (what, when) Assignment to developers Monitoring  measuring  planning • Cannot be codified or standardized • Process and project size • Iterative and incremental Software process models are general approaches for organizing a Project into activities.
  • 17. Process – Help the project manager and his or her team to decide: • What work should be done; • In what sequence to perform the work. – The models should be seen as aids to thinking, not rigid prescriptions of the way to do things. – Each project ends up with its own unique plan.
  • 18. The opportunistic approach Think of Idea for Improvement Modify Until Satisfied First Prototype
  • 19. The opportunistic approach … is what occurs when an organization does not follow good engineering practices. – It does not acknowledge the importance of working out the requirements and the design before implementing a system. – The design of software deteriorates faster if it is not well designed. – Since there are no plans, there is nothing to aim towards. – There is no explicit recognition of the need for systematic testing and other forms of quality assurance. – The above problems make the cost of developing and maintaining software very high.
  • 20. The waterfall model The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance. – The model suggests that software engineers should work in a series of stages. – Before completing each stage, they should perform quality assurance (verification and validation). – The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.
  • 21. The waterfall model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Maintenance V & V Integration and Deployment
  • 22. Limitations of the waterfall model – The model implies that you should attempt to complete a given stage before moving on to the next stage • Does not account for the fact that requirements constantly change. • It also means that customers can not use anything until the entire system is complete. – The model makes no allowances for prototyping. – It implies that you can get the requirements right by simply writing them down and reviewing them. – The model implies that once the product is finished, everything else is maintenance.
  • 23. The phased-release model It introduces the notion of incremental development. – After requirements gathering and planning, the project should be broken into separate subprojects, or phases. – Each phase can be released to customers when ready. – Parts of the system will be available earlier than when using a strict waterfall approach. – However, it continues to suggest that all requirements be finalized at the start of development.
  • 24. The phased-release model V & V Requirements Gathering and Definition V & V Specification V & V Design V & V Implementation V & V Planning Phase 1 V & V Design V & V Implementation Phase 2 etc ... V & V Integration and Deployment V & V Integration and Deployment
  • 25. The spiral model It explicitly embraces prototyping and an iterative approach to software development. – Start by developing a small prototype. – Followed by a mini-waterfall process, primarily to gather requirements. – Then, the first prototype is reviewed. – In subsequent loops, the project team performs further requirements, design, implementation and review. – The first thing to do before embarking on each new loop is risk analysis. – Maintenance is simply a type of on-going development.
  • 26. The spiral model Requirements Specification Design Implementation Prototype Release 1 Release 2 Review Analysis of risk Integration and deployment
  • 27. The evolutionary model It shows software development as a series of hills, each representing a separate loop of the spiral. – Shows that loops, or releases, tend to overlap each other. – Makes it clear that development work tends to reach a peak, at around the time of the deadline for completion. – Shows that each prototype or release can take • different amounts of time to deliver; • differing amounts of effort.
  • 29. The concurrent engineering model It explicitly accounts for the divide and conquer principle. – Each team works on its own component, typically following a spiral or evolutionary approach. – There has to be some initial planning, and periodic integration.
  • 30. The concurrent engineering model Plan Integrate Divide Work on Component or Layer X Work on Component or Layer B Work on Component or Layer A ...
  • 31. Choosing a process model – From the waterfall model: • Incorporate the notion of stages. – From the phased-release model: • Incorporate the notion of doing some initial high-level analysis, and then dividing the project into releases. – From the spiral model: • Incorporate prototyping and risk analysis. – From the evolutionary model: • Incorporate the notion of varying amounts of time and work, with overlapping releases. – From the concurrent engineering: • Incorporate the notion of breaking the system down into components and developing them in parallel.
  • 32. Reengineering Periodically project managers should set aside some time to re-engineer part or all of the system – The extent of this work can vary considerably: • Cleaning up the code to make it more readable. • Completely replacing a layer. • Re-factoring part of the design. – In general, the objective of a re-engineering activity is to increase maintainability.
  • 33. Software development invariant Software production is an art – Software is developed, not manufactured …but we can customize: • Re-use (algorithms, code libraries, classes, software) • COTS (commercial-of-the-shelf solutions) • ERP (Enterprise Resource Planning systems) – … but what about core business? • Component technology – CORBA – DCOM – EJB
  • 34. People in the process People are an organisation‟s most important assets. The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. Poor people management is an important contributor to project failure.
  • 35. People management factors Consistency – Team members should all be treated in a comparable way without favourites or discrimination. Respect – Different team members have different skills and these differences should be respected. Inclusion – Involve all team members and make sure that people‟s views are considered. Honesty – You should always be honest about what is going well and what is going badly in a project.
  • 36. Selecting staff An important project management task is team selection. Information on selection comes from: – Information provided by the candidates. – Information gained by interviewing and talking with candidates. – Recommendations and comments from other people who know or who have worked with the candidates.
  • 37. Project staffing May not be possible to appoint the ideal people to work on a project – Project budget may not allow for the use of highly-paid staff; – Staff with the appropriate experience may not be available; – An organisation may wish to develop employee skills on a software project. Managers have to work within these constraints especially when there are shortages of trained staff.
  • 38. Building Software Engineering Teams Software engineering is a human process. – Choosing appropriate people for a team, and assigning roles and responsibilities to the team members, is therefore an important project management skill – Software engineering teams can be organized in many different ways on the basis of problem of different complexities and sizes.
  • 39. Types of Development Team Closed (tactical) traditional leadership stable and secure can be over-controlled operates in a group-oriented way good for routine projects Random (breakthrough) bottom-up decision making promotes creativity chaotic, competitive operates in a chaotic, undirected way good for creative breakthroughs Open (problem-solving) decision-making by consensus adapt to & solve complex problems chaotic, might not solve anything operates in a flexible, explorative way works best on solving complex problems L. Constantine, 1993. Work Organization: Paradigms for Project Management and Organization. CACM October 1993, pp. 35-44. Synchronous (vision-sharing) decisions implied by visions efficient, smooth can drift, lose sight of reality operates in a coordinated way repetitive problems, high performance
  • 40. Team Structure • Egoless/Democratic team • Chief-programmer team • Strict hierarchy/Mixed organization a) Egoless b) Chief programmer c) Strict hierarchy
  • 41. Egoless/Democratic Teams Democratic organization provides – In such a team everybody is equal, and the team works together to achieve a common goal. – Decisions are made by consensus. – Most suited to difficult projects with many technical challenges. – higher morale and job satisfaction to the engineers – therefore leads to less employee turnover. Suitable for less understood problems, – a group of engineers can invent better solutions than a single individual.
  • 42. Democratic Teams Disadvantage: –team members may waste a lot time arguing about trivial points: •absence of any authority in the team.
  • 43. Chief Programmer Team A senior engineer provides technical leadership: – partitions the task among the team members. – verifies and integrates the products developed by the members.
  • 44. Chief Programmer Team Works well when – the task is well understood • also within the intellectual grasp of a single individual, – importance of early completion outweighs other factors • team morale, personal development, etc.
  • 45. Chief programmer team is subject to single point failure: – too much responsibility and authority is assigned to the chief programmer. Chief Programmer Team
  • 46. Group Leadership Leadership depends on respect. What kind of leadership? – Technical – Administrative – Co-leaders – Collective leadership Democratic is better than autocratic.
  • 47. The Team Leader Project management is a people-oriented activity – People with great technical skills don‟t necessarily make good team leaders – people skills are needed too Weinberg suggests an MOI model of leadership – Motivation • Ability to encourage technical people to work to the best of their abilities (push or pull) – Organization • Ability to adapt existing processes, or devise new ones, to enable the concept to be turned into a product – Ideas/Innovation • Ability to encourage people to create, and to feel creative, within the bounds of the particular product Team leader must let everyone know, by words and deeds, that quality is important – lead by example!
  • 48. The Team Leader Another view of what makes a good team leader: – Problem solving • Decide which technical and organizational issues are most important • Create a systematic solution to the problem – or motivate others to do so • Apply lessons from past projects to new ones • Remain flexible enough to change direction if initial proposed solution doesn‟t work – Managerial Identity • Confidence to take charge of project when necessary, but also to let good technical people use their initiative – Achievement • Reward initiative and accomplishment • Demonstrate that controlled risk-taking will not be punished – Influence and Team building • Be able to “read” people – understand both verbal and non-verbal signals from team members, and react to their needs
  • 49. Strict hierarchy/Mixed Control Team Organization Draws upon ideas from both: – democratic organization and – chief-programmer team organization. Communication is limited – to a small group that is most likely to benefit from it. Suitable for large organizations
  • 50. Choosing an effective size for a team – For a given estimated development effort, in person months, there is an optimal team size. • Doubling the size of a team will not halve the development time. – Subsystems and teams should be sized such that the total amount of required knowledge and exchange of information is reduced. – For a given project or project iteration, the number of people on a team will not be constant. – You can not generally add people if you get behind schedule, in the hope of catching up.
  • 51. Skills needed on a team – Architect – Project manager – Configuration management and build specialist – User interface specialist – Technology specialist – Hardware and third-party software specialist – User documentation specialist – Tester
  • 52. Motivating people An important role of a manager is to motivate the people working on a project. Motivation is a complex issue but it appears that their are different types of motivation based on: – Basic needs (e.g. food, sleep, etc.); – Personal needs (e.g. respect, self-esteem); – Social needs (e.g. to be accepted as part of a group).
  • 53. Human needs hierarchy Ph ysiolo g ical need s Safety need s So cial n eeds Esteemn eeds Self- r ealisa tion needs
  • 54. Need satisfaction Social – Provide communal facilities; – Allow informal communications. Esteem – Recognition of achievements; – Appropriate rewards. Self-realization – Training - people want to learn more; – Responsibility.
  • 55. Personality types The needs hierarchy is almost certainly an over-simplification of motivation in practice. Motivation should also take into account different personality types: – Task-oriented; – Self-oriented; – Interaction-oriented.
  • 56. Personality types Task-oriented. – The motivation for doing the work is the work itself; Self-oriented. – The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc.; Interaction-oriented – The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work.
  • 57. Motivation balance Individual motivations are made up of elements of each class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal factors but also by being part of a group and culture. People go to work because they are motivated by the people that they work with.
  • 58. Managing groups Most software engineering is a group activity – The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. Group interaction is a key determinant of group performance. Flexibility in group composition is limited – Managers must do the best they can with available people.
  • 59. Factors influencing group working Group composition. Group cohesiveness. Group communications. Group organisation.
  • 60. Group composition Group composed of members who share the same motivation can be problematic – Task-oriented - everyone wants to do their own thing; – Self-oriented - everyone wants to be the boss; – Interaction-oriented - too much chatting, not enough work. An effective group has a balance of all types. This can be difficult to achieve software engineers are often task-oriented. Interaction-oriented people are very important as they can detect and defuse tensions that arise.
  • 61. Leadership depends on respect not titular status. There may be both a technical and an administrative leader. Democratic leadership is more effective that autocratic leadership. Group leadership
  • 62. Group cohesiveness In a cohesive group, members consider the group to be more important than any individual in it. The advantages of a cohesive group are: – Group quality standards can be developed; – Group members work closely together so inhibitions caused by ignorance are reduced; – Team members learn from each other and get to know each other‟s work; – Egoless programming where members strive to improve each other‟s programs can be practised.
  • 63. Developing cohesiveness Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group. Cohesiveness can be encouraged through – Social events; – Developing a group identity and territory; – Explicit team-building activities. Openness with information is a simple way of ensuring all group members feel part of the group.
  • 64. Group members tend to be loyal to cohesive groups. 'Groupthink' is preservation of group irrespective of technical or organizational considerations. Management should act positively to avoid groupthink by forcing external involvement with each group. Group loyalties
  • 65. Group communications Good communications are essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions. Good communications also strengthens group cohesion as it promotes understanding.
  • 66. Group size – The larger the group, the harder it is for people to communicate with other group members. Group structure – Communication is better in informally structured groups than in hierarchically structured groups. Group composition – Communication is better when there are different personality types in a group and when groups are mixed rather than single sex. The physical work environment – Good workplace organisation can help encourage communications. Group communications
  • 67. Group organisation Small software engineering groups are usually organised informally without a rigid structure. For large projects, there may be a hierarchical structure where different groups are responsible for different sub- projects.
  • 68. Informal groups The group acts as a whole and comes to a consensus on decisions affecting the system. The group leader serves as the external interface of the group but does not allocate specific work items. Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience. This approach is successful for groups where all members are experienced and competent.
  • 69. Extreme programming groups Extreme programming groups are variants of an informal, democratic organisation. In extreme programming groups, some „management‟ decisions are devolved to group members. Programmers work in pairs and take a collective responsibility for code that is developed.
  • 70. The physical workplace provision has an important effect on individual productivity and satisfaction – Comfort; – Privacy; – Facilities. Health and safety considerations must be taken into account – Lighting; – Heating; – Furniture. Working environments
  • 71. Privacy - each engineer requires an area for uninterrupted work. Outside awareness - people prefer to work in natural light. Personalization - individuals adopt different working practices and like to organize their environment in different ways. Environmental factors
  • 72. Workspace organisation Workspaces should provide private spaces where people can work without interruption – Providing individual offices for staff has been shown to increase productivity. However, teams working together also require spaces where formal and informal meetings can be held.
  • 74. Sample sets of tasks – Meet with client and decide on scope of project – Develop information gathering plan – Design survey – Get authorization for survey – Pilot-test survey – Revise survey – Select sample for survey – Administer survey – Analyze survey results – Compile list of candidate systems – Develop template for comparing alternatives – Decide on "short list" – Do detailed technical analysis of alternatives – Do detailed cost analysis of alternatives
  • 75. Sample sets of tasks Tasks (continued) – Draft comparative sections of report – Revise comparative sections of report – Write implementation plan – Write evaluation plan – Write final report – Prepare oral presentation And here are the milestones: – Submit information gathering protocol and instrument – Submit progress report – Submit economic feasibility report – Submit process diagram(s) – Submit final report – Give oral presentation
  • 76. Project Scope In Traditional Project Management (TPM), it is assumed that you can determine the goal of the project from the onset – The adaptive or extreme management methods examined later will allow this not to be true Capture key project objectives in the Project Overview Statement (POS)
  • 77. Role of the POS The POS captures key objectives of the project, such as the Conditions of Satisfaction (COS) – It should be a short document (1-2 pp) – The COS should convey what the project is expected to deliver and accomplish – It should be reviewed and updated throughout the project – it isn‟t static – It is negotiated with the customer
  • 78. Role of the POS The POS is a communications tool among the project manager, their development team, the customer, and the project manager‟s boss (upper or senior management) The POS is a concise statement of the project, and a summary of its justification to continue
  • 79. Other Views The POS and COS are often known by other terms, like the Vision or Mission of the project – POS and COS are Wysocki‟s terminology
  • 80. Generating the POS Often the POS is developed through an iterative process – The customer makes a request for some major aspect of the product (key set of features, for example) – The developer asks to clarify the request – The customer provides a response – Customer and developer agree on the response – Repeat the previous four steps until done
  • 81. Non-traditional POS Uses The POS can help understand a project even if not starting from scratch – Inheriting a project from someone else – Using a POS as a suggestion to start an unsolicited project – Use a POS as a reference to guide your team during development
  • 82. Parts of a POS The POS has five major sections – Problem/opportunity – Goal – Objectives – Success criteria – Assumptions, risks, obstacles Each is typically a few paragraphs long
  • 83. Problem/opportunity This section summarizes major problems the project will fix, and identify significant new opportunities of which it will take advantage – Like the INFO 503 analysis method of the same name, this helps prove there is significant motivation for the project to occur
  • 84. Goal The goal gives direction and purpose to the project, summarizing how the organization will address the problems, or act on the opportunities Don‟t commit to specific time or cost goals – the scope of the project is too vague for that
  • 85. Objectives The objective statements elaborate on the goal, and clarify its scope or boundaries – If you meet all the objectives, then the goal must also be met – Each objective should define an expected outcome, the rough time frame it will be done, a measure, and the action needed to meet the objective
  • 86. Success criteria Imagine the project is done, and you want to prove how much the organization benefited from it – What specific measures could you make to prove the project was worthwhile? – These are your success criteria Typical criteria are increased revenue, reduced costs, improved service, etc.
  • 87. Assumptions, risks, obstacles This is an executive summary of major assumptions the project is based upon, key risks to manage, and foreseeable obstacles that will need to be overcome – Particularly focus on areas you might need help managing More details will appear in the Project Definition Statement (PDS)
  • 88. POS Attachments The POS can have attachments for more information on the project Most common are – A risk analysis (to show more detail than given earlier), and/or – A financial analysis (such as cost-benefit analysis, feasibility studies, ROI, etc.)
  • 89. POS Approval The POS is submitted to middle or upper management for approval The expected outcome is to continue more detailed planning and analysis for the project
  • 90. Expand POS into PDS The Project Definition Statement (PDS) expands on the POS in two key areas – Objectives can be more specific, and use more technical language to convey their exact intent – Assumptions, risks, obstacles can cover more details of interest to the development team
  • 92. Objectives What Software Project Managers need to know to: Identify the types of reviews and meetings Understand when and why to hold reviews and meetings Use the 10 Steps to productive reviews and meetings
  • 93. Types of Reviews and Meetings Technical Reviews Address technical issues: requirements, design, code Example: Formal Inspections Management Reviews Address project issues: status, budget, schedule Example: Design Review Meetings Gathering of people for a business purpose Examples: staff meetings, committee meetings, training sessions
  • 94. Technical Reviews • Address technical issues: evolving software products, services, solutions • Are attended only by persons with technical knowledge of the subject matter, not management - Includes both acquirer and developer technical personnel - In requirements phase includes customers, users - Includes SQA, SCM, V&V, test as needed • Report the actual technical status of the project to management • Identify risks and issues to be raised at Management Reviews • Examples: Formal Inspection Code walkthrough Design tradeoff meeting Process review
  • 95. Technical Review Criteria for a Software Product or Service Is it complete? Does it comply with standards and specifications? Are changes properly implemented? Does it adhere to the applicable schedule? Is it ready for the next planned activity? Is development being conducted according to the plans, standards, and guidelines of the project?
  • 96. Technical Reviews provide inputs to Management Reviews Technical Review resolve defects Technical Review resolve defects Prelim I’face Spec. Management Review (software design review) Technical Review resolve defects Plan Prelim Reqts. Spec. status risks issues concerns questions
  • 97. Management Reviews • Address project issues: status versus plans, schedules, standards • Keep management informed about status, direction, agreements • Are attended by technical leaders, project managers, and managers (with decision authority over cost and schedule) • Identify and resolve risks - Are we ready to continue? Should we continue? • Receive input, resolve issues from several Technical Reviews • Examples: Requirements review Design review Test readiness review
  • 98. Management Review Criteria Is progress according to plan? Are schedules, standards, and guidelines being followed? Are resources adequately allocated? Are risks jeapordizing success? Are we making good decisions based on metrics? Do we need to change direction or revise plans?
  • 99. Management Review Terminology DOD-STD-2167A MIL-STD-498 IEEE/EIA 12207 Formal Reviews (10) Joint Mgmt. Reviews (11) Project mgmt. reviews (11) Software plan review Software plan review Operational concept review Operational concept review System Reqts. Rev.(SRR) System/subsys. reqts rev. System/subsys. reqts rev. System Design Rev.(SDR) System/subsys. design rev. System/subsys design rev. Software Spec. Rev. (SSR) Software reqts review Software reqts. review Prelim Design Rev. (PDR) Critical Design Rev. (CDR) Software design review Software design review Test Readiness Rev. (TRR) Test readiness review Test readiness review Test results review Test results review Production Readiness Rev(PRR) -- -- Software usability review Software maintenance rev. Software supportability rev. Software supportability rev. Critical reqts. review Critical reqts. review Functional Config Audit (FCA) (FCA in MIL-STD-973) (FCA in IEEE Std 1042) Physical Config Audit (PCA) (PCA in MIL-STD-973) (PCA in IEEE Std 1042) Formal Qual. Review (FQR) (dropped by MIL-STD-073) -- (see MIL-STD-1521B) (see 498 Appendix E) (see 12207.2 Annex G) (see also IEEE Std 1028)
  • 100. SSC SD Management Project/Design Reviews SPAWARSYSCEN SAN DIEGO INST 3912.1A of 18 Dec 1997 Development projects will be subject to periodic review Purpose: to help project managers meet cost, schedule, and technical requirements SC SD Department Heads to identify applicable projects Program Managers to adhere to policies and procedures Design Review Committee to coordinate reviews Review topics: Management practices Technical processes Requirements and approaches Test and evaluation Schedule and budget Documentation plans/status Procurement status Product assurance plans/status Instruction available at: http://iweb.spawar.navy.mil/services/sti/publications/inst/subjects.html
  • 101. Purposes: Convey information to a group Solicit information Answer questions Brainstorm Make a decision as a group Convince or persuade team of idea Maintain team spirit, involvement Examples: Weekly Status Meeting All-Hands Meeting Committee Meeting “Are you lonely? Working on your own? Hate making decisions? HOLD A MEETING!” Meetings
  • 102. Question: What are the Consequences of Poorly- Run Reviews and Meetings?
  • 103. The Steps to Successful Reviews and Meetings
  • 104. • Determine type of review/meeting: Technical Review, Management Review, program review, status meeting, staff meeting, etc. • What outcome or decision do you expect to reach? • Should be goal-oriented, value-added, and primarily non-adversarial Examples: “Reach agreement on interface requirements.” “Review project status and risks to determine if requirements need to be reduced.” “Announce the new project organization and decide on new office spaces.” Step 1: Establish Type of Review/Meeting and the G______ and O____________
  • 105. Step 2: Establish E_______ C_________ and E______ C_________ • Entrance criteria: What must occur prior to the review or meeting in order to make it successful Derived from goals/objectives Examples: Completion of the work product to be approved All attendees read IRS, review risks • Exit criteria: What must be accomplished for the review or meeting to be closed Example: Identify and document all discrepancies • Both must be established prior to review/meeting
  • 106. Step 3: Be Organized; Be Prepared • Select the right participants - get a good mix - Invite only those who have a stake in the outcome - Continuity of participants is important!! • Assign roles: leader, facilitator, timekeeper, recorder • Have an agenda - keep to it - Hand out agenda ahead of time • Insist that participants be prepared
  • 107. Step 4: * Hold a kick-off meeting for Reviews • Review goals/objectives of the review with the developer (participants) - Schedule at least two weeks prior to the meeting - Doesn’t have to be face-to-face in the same room, could be video teleconference or phone call Example: Formal Inspection Overview Meeting * - applies to reviews only
  • 108. Step 5: *Hold a Government-only pre-review meeting (if applicable) • Evaluate goals/objectives of the review, controversial areas, known deficiencies • Purpose is to achieve Government consensus • Most important if multiple Government agencies are involved * - applies to Management Review only
  • 109. Step 6: Get Off to a Good Start • Make the participants feel comfortable - Ensure adequate facilities (space, lights, air conditioning, ...) - Set up room to accommodate the objective (for best communications, use U-shaped or oval) • Arrange for food, drinks, breaks • Provide welcome and introductions • Summarize roles, goals, objectives, agenda • Verify that Entrance Criteria have been met
  • 110. Step 7: Establish Ground Rules • Getting everyone’s input - Use round robin or query those not contributing - Show appreciation for constructive participation - Encourage open communication - Use everyone’s talents--that is why they are there • Limiting the number and length of presentations - Agree on time limits, assign timekeeper • Controlling the group size - If the group is over 10, divide the group into smaller teams to divide up the issue to be discussed • Using prototypes to assist participants in understanding and communication • Handling disagreements or conflicts
  • 111. Step 8: Take M__________ of Proceedings and Assign A________ I________ • Sample contents: Review name and objectives Attendees Results and Decisions Action Items •Assign action items for open issues - Specify due date, priority, and responsible person • Review action items and decisions prior to close of review/meeting - Action Items that can be answered during the review/meeting should be answered then and allow time for more detailed analysis of more profound Action Items • Confirm that Exit Criteria are met • Send out minutes in a timely manner for review and comment
  • 112. Step 9: Request F__________ on how to improve the review/meeting process • Reviews and meetings span the life of all projects • All attendees want reviews and meetings to be productive • Example feedback questions - Was the agenda available beforehand? - How can we foster better communication? - Do we have the right attendees? - Were the physical facilities adequate? - How can our reviews and meetings be improved?
  • 113. Step 10: Track, Follow-up on A_______ I______ • Establish an Action Item tracking system Sample Contents: A.I. number Description Priority Date Assigned Responsible person(s) Estimated Completion Date Status Date Closed • Collect the metric: outstanding action items - Measures the health of a software project • Schedule an in-progress (status) review or meeting if needed • Prepare for next review/meeting
  • 114. Summary: The Steps to Successful Reviews and Meetings 1. Establish type of review/meeting and the goals and objectives 2. Establish entrance criteria and exit criteria 3. Be organized, be prepared 4. Hold a kick-off meeting (for Reviews only) 5. Hold a Government-only pre-review meeting (for reviews only) 6. get off to a good start 7. Establish ground rules 8. Take minutes of proceedings and assign action items 9. Request feedback on how to improve the review/meeting process 10. Track, follow up on action items
  • 115. The Software Project Manager shall: • Conduct reviews and meetings when appropriate • Separate technical reviews from management reviews • Apply the 10 key steps to make them successful
  • 116. Formal Technical Reviews (FTR) An FTR is a quality assurance activity performed by software engineers (and others) Objectives – Uncover errors in function, logic or implementation for any representation of software – Verify that software being reviewed meets its requirements – Ensure that software is represented according to relevant standards (e.g. Structured A&D, UML) – Achieve uniform software development – Make projects more manageable – Train junior software engineers FTRs include walkthroughs, inspections and other small group software assessments
  • 117. FTRs: Constraints FTRs are conducted as meetings, and will only be successful if properly planned, controlled and attended Basic constraints for FTRS: – Typically involve three to five people – Participants should do advance preparation (no more than two hours work) – Review meeting should take no more than two hours To meet these constraints, the FTR must focus on a specific (and small) part of the software By reducing scope of the FTR, the chance of uncovering errors is increased
  • 118. FTRs: Preparation Preparation for an FTR – Person who developed the work product – the producer – informs the team leader that it is ready for review – Team leader designates a review leader, who evaluates the product‟s readiness and distributes copies of product material to two or three other reviewers – Each reviewer spends one or two hours reviewing the product and making notes on it – At the same time, the review leader also reviews the product, establishes an agenda for the review meeting and schedules a meeting time
  • 119. FTRs: The Meeting The FTR meeting – Meeting is attended by producer, review leader and all reviewers – One reviewer acts as a recorder, who notes in writing all the important issues raised during the review – Start by going over the agenda, and a brief introduction to the product from the producer – Producer then proceeds to “walk-though” the product, explaining it as he/she goes • Reviewers raise issues based on their advance preparation • When valid problems or errors are discovered, they are noted by the recorder – At end of meeting, all participants must decided whether to • Accept the product as is • Reject the product due to severe problems (redevelopment and another review required) • Accept the product provisionally (minor errors, as noted, must be corrected, but no further review required)
  • 120. FTRs: Reporting Review Reporting and Recording – After the review meeting, the recorder produces a review summary report, answering the questions: • What was reviewed? • Who reviewed it? • What were the findings and conclusions? – Review summary report is typically a single page, possibly with attachments – A review issues list should also be created and attached to the summary report. It notes: • Problem areas within the product • An action item checklist which guides the producer as corrections are made – The review leader should have follow-up contact with the producer to ensure that the issues have been addressed
  • 121. FTRs: Guidelines Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Identify problem areas but don‟t attempt to solve every problem Take written notes Limit the number of participants Insist on advance preparation Develop a checklist for each work product Allocate resources and time Conduct meaningful training Review earlier reviews
  • 122. FTRs: Effectiveness Catch up to 75% of design errors Can be up to three times more effective than testing at finding errors Involve time, effort and money, but provide a demonstrable cost benefit in the overall development
  • 123. Project Agreement Document written for a client that defines: – the scope, duration, cost and deliverables for the project. – the exact items, quantities, delivery dates, delivery location. Client: Individual or organization that specifies the requirements and accepts the project deliverables. Can be a contract, a statement of work, a business plan, or a project charter. Deliverables (= Work Products that will be delivered to the client: – Documents – Demonstrations of function – Demonstration of nonfunctional requirements – Demonstrations of subsystems
  • 124. Types of Contracts Fixed price or lump sum: involve a fixed total price for a well-defined product or service Cost reimbursable: involve payment to the seller for direct and indirect costs Time and material contracts: hybrid of both fixed price and cost reimbursable, often used by consultants Unit price contracts: require the buyer to pay the seller a predetermined amount per unit of service
  • 125. Cost Reimbursable Contracts Cost plus incentive fee (CPIF) – Buyer pays seller for allowable performance costs plus a predetermined fee and an incentive bonus Cost plus fixed fee (CPFF) – Buyer pays seller for allowable performance costs plus a fixed fee payment usually based on a percentage of estimated costs Cost plus percentage of costs (CPPC) – Buyer pays seller for allowable performance costs plus a predetermined percentage based on total costs
  • 127. Statement of Work (SOW) A description of the work required for the project Sets the “boundary conditions” SOW vs. CSOW (Contract SOW) – Latter: uses legal language as part of a competitive bidding scenario Can be used in the final contract – be careful, be specific, be clear
  • 128. SOW Continued Typically done after approval (after “Go”) Can be multiple versions – 1. List of deliverables for an RFP – 2. More detailed within final RFP – 3. Binding version from contract
  • 129. SOW Template I. S co p e o f W o rk : D escrib e th e w o rk to b e d o n e to d etail. S p ecify th e h a rd w are an d so ftw are in v o lv ed an d th e ex act n atu re o f th e w o rk . II. L o ca tio n o f W o rk : D escrib e w h ere th e w o rk m u st b e p erfo rm ed . S p ecify th e lo catio n o f h ard w are an d so ftw are an d w h e re th e p eo p le m u st p erfo rm th e w o rk III. P e rio d o f P erfo r m a n c e: S p ecify w h en th e w o rk is ex p ected to start an d en d , w o rk in g h o u rs, n u m b er o f h o u rs th at can b e b illed p er w e ek , w h e re th e w o rk m u st b e p erfo rm ed , an d relate d sch ed u le in fo rm atio n . O p tio n al “C o m p en satio n ” sectio n . IV . D eliv era b les S ch ed u le: L ist sp ecific d eliv erab les, d escrib e th em in d etail, an d sp ecify w h en th e y are d u e. V . A p p lica b le S ta n d a rd s: S p ecify an y co m p an y o r in d u stry -sp e cific stan d ard s th at are relev an t to p e rfo rm in g th e w o rk . O ften an A ssu m p tio n s sectio n as w ell. V I. A ccep ta n c e C riteria : D escrib e h o w th e b u yer o rg an iz atio n w ill d eterm in e if th e w o rk is acc ep tab le. V II. S p ecia l R eq u irem en ts: S p ecify an y sp e cial req u irem en ts su ch as h ard w are o r so ftw are certific atio n s, m in im u m d eg re e o r ex p erien ce lev el o f p e rso n n el, trav el req u irem en ts, d o cu m en ta tio n , testin g , su p p o rt, an d so o n .
  • 130. Project Charter A high-level project description: – Business need, product, assumptions Often precedes SOW Often 2-4 pages (can be longer)
  • 131. Project Charter Typical outline – Overview • Business need • Objectives • Method or approach – General scope of work – Rough schedule & budget – Roles & responsibilities – Assumptions
  • 132. Organization of SPMP Document – Introduction (Objectives,Major Functions,Performance Issues,Management and Technical Constraints) – Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates) – Project Resources Plan(People,Hardware and Software,Special Resources) – Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart Representation) – Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures) – Project Tracking and Control Plan – Miscellaneous Plans(Process Tailoring,Quality Assurance)
  • 133. Work Breakdown Structure: WBS Hierarchical list of project‟s work activities 2 Formats – Outline (indented format) – Graphical Tree (Organizational Chart) Uses a decimal numbering system – Ex: 3.1.5 – 0 is typically top level Includes – Development, Mgmt., and project support tasks Shows “is contained in” relationships Does not show dependencies or durations
  • 134. WBS Contract WBS (CWBS) – First 2 or 3 levels – High-level tracking Project WBS (PWBS) – Defined by PM and team members – Tasks tied to deliverables – Lowest level tracking
  • 135. A Full WBS Structure Up to six levels (3-6 usually) such as Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses – Ex: Level 1: authorizations; 2: budgets; 3: schedules
  • 137. WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
  • 138. WBS Types Process WBS • a.k.a Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM Product WBS • a.k.a. Entity-oriented • Ex: Financial engine, Interface system, DB • Typically used by engineering manager Hybrid WBS: both above • This is not unusual • Ex: Lifecycle phases at high level with component or feature-specifics within phases • Rationale: processes produce products
  • 142. WBS by PMI Process Groups
  • 143. WBS Types Less frequently used alternatives – Organizational WBS • Research, Product Design, Engineering, Operations • Can be useful for highly cross-functional projects – Geographical WBS • Can be useful with distributed teams • NYC team, San Jose team, Off-shore team
  • 144. Work Packages Generic term for discrete tasks with definable end results Typically the “leaves” on the tree The “one-to-two” rule • Often at: 1 or 2 persons for 1 or 2 weeks Basis for monitoring and reporting progress • Can be tied to budget items (charge numbers) • Resources (personnel) assigned Ideally shorter rather than longer • Longer makes in-progress estimates needed • These are more subjective than “done” • 2-3 weeks maximum for software projects • 1 day minimum (occasionally a half day) • Not so small as to micro-manage
  • 145. WBS List of Activities, not Things List of items can come from many sources – SOW, Proposal, brainstorming, stakeholders, team Describe activities using “bullet language” – Meaningful but terse labels All WBS paths do not have to go to the same level Do not plan more detail than you can manage
  • 146. WBS & Methodology PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all – Planning, configuration, testing Operations and maintenance phases are not normally in plan (considered post-project) Some models are “straightened” for WBS – Spiral and other iterative models – Linear sequence several times Deliverables of tasks vary by methodology
  • 147. WBS Techniques Top-Down Bottom-Up Analogy Rolling Wave – 1st pass: go 1-3 levels deep – Gather more requirements or data – Add more detail later Post-its on a wall
  • 148. WBS Techniques Top-down – Start at highest level – Systematically develop increasing level of detail – Best if • The problem is well understood • Technology and methodology are not new • This is similar to an earlier project or problem – But is also applied in majority of situations
  • 149. WBS Techniques Bottom-up – Start at lowest level tasks – Aggregate into summaries and higher levels – Cons • Time consuming • Needs more requirements complete – Pros • Detailed
  • 150. WBS Techniques Analogy – Base WBS upon that of a “similar” project – Use a template – Analogy also can be estimation basis – Pros • Based on past actual experience – Cons • Needs comparable project
  • 151. WBS Techniques Brainstorming – Generate all activities you can think of that need to be done – Group them into categories Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!)
  • 152. WBS – Basis of Many Things Network scheduling Costing Risk analysis Organizational structure Control Measurement
  • 153. WBS Guidelines Part 1 Should be easy to understand Some companies have corporate standards for these schemes Some top-level items, like Project Mgmt. are in WBS for each project – Others vary by project What often hurts most is what‟s missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable
  • 154. WBS Guidelines Part 2 How detailed should it be? – Not as detailed as the final MS-Project plan – Each level should have no more than 7 items – It can evolve over time What tool should you use? – Excel, Word, Project – Org chart diagramming tool (Visio, etc) – Specialized commercial apps Re-use a “template” if you have one
  • 155. Software Cost Estimation Determine size of the product. From the size estimate, – determine the effort needed. From the effort estimate, – determine project duration, and cost.
  • 156. Financial Analysis of Projects Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects: – Net present value (NPV) analysis – Return on investment (ROI) – Payback analysis
  • 157. Net Present Value Analysis: NPV NPV: a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better
  • 159. Return on Investment (ROI) ROI: income divided by investment ROI = (total discounted benefits - total discounted costs) / discounted costs The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on investment for projects
  • 160. Payback Analysis Another important financial consideration is payback analysis The “payback period” is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project Payback occurs when the cumulative discounted benefits and costs are greater than zero Many organizations want IT projects to have a fairly short payback period
  • 161. NPV, ROI, Payback Period: Ex 1
  • 162. NPV, ROI, Payback Period: Ex 2
  • 163. Weighted Scoring Model A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria • First identify criteria important to the project selection process • Then assign weights (percentages) to each criterion so they add up to 100% • Then assign scores to each criterion for each project • Multiply scores * weights = total weighted scores The higher the weighted score, the better
  • 166. Software Cost Estimation Three main approaches to estimation: –Empirical –Heuristic –Analytical
  • 167. Software Cost Estimation Techniques Empirical techniques: – an educated guess based on past experience. Heuristic techniques: – assume that the characteristics to be estimated can be expressed in terms of some mathematical expression. Analytical techniques: – derive the required results starting from certain simple assumptions.
  • 168. Software Size Metrics LOC (Lines of Code): – Simplest and most widely used metric. – Comments and blank lines should not be counted.
  • 169. Disadvantages of Using LOC Size can vary with coding style. Focuses on coding activity alone. Correlates poorly with quality and efficiency of code. Penalizes higher level programming languages, code reuse, etc.
  • 170. Disadvantages of Using LOC (cont...) Measures lexical/textual complexity only. – does not address the issues of structural or logical complexity. Difficult to estimate LOC from problem description. – So not useful for project planning
  • 171. Function Point Metric Overcomes some of the shortcomings of the LOC metric Proposed by Albrecht in early 80's: – FP=4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces Input: – A set of related inputs is counted as one input.
  • 172. Function Point Metric Output: – A set of related outputs is counted as one output. Inquiries: – Each user query type is counted. Files: – Files are logically related data and thus can be data structures or physical files. Interface: – Data transfer to other systems.
  • 173. Function Point Metric(CONT.) Suffers from a major drawback: – the size of a function is considered to be independent of its complexity. Extend function point metric: – Feature Point metric: – considers an extra parameter: •Algorithm Complexity.
  • 174. Function Point Metric(CONT.) Proponents claim: – FP is language independent. – Size can be easily derived from problem description Opponents claim: – it is subjective --- Different people can come up with different estimates for the same problem.
  • 175. Empirical Size Estimation Techniques Expert Judgement: – An euphemism for guess made by an expert. – Suffers from individual bias. Delphi Estimation: – overcomes some of the problems of expert judgement.
  • 176. Expert judgement Experts divide a software product into component units: – e.g. GUI, database module, data communication module, billing module, etc. Add up the guesses for each of the components.
  • 177. Delphi Estimation: Team of Experts and a coordinator. Experts carry out estimation independently: – mention the rationale behind their estimation. – coordinator notes down any extraordinary rationale: •circulates among experts.
  • 178. Delphi Estimation: Experts re-estimate. Experts never meet each other – to discuss their viewpoints.
  • 179. Heuristic Estimation Techniques Single Variable Model: – Parameter to be Estimated=C1(Estimated Characteristic)d1 Multivariable Model: – Assumes that the parameter to be estimated depends on more than one characteristic. – Parameter to be Estimated=C1(Estimated Characteristic)d1+ C2(Estimated Characteristic)d2+… – Usually more accurate than single variable models.
  • 180. COCOMO Model COCOMO (COnstructive COst MOdel) proposed by Boehm. Divides software product developments into 3 categories: – Organic – Semidetached – Embedded
  • 181. COCOMO Product classes Roughly correspond to: – application, utility and system programs respectively. •Data processing and scientific programs are considered to be application programs. •Compilers, linkers, editors, etc., are utility programs. •Operating systems and real-time system programs, etc. are system programs.
  • 182. Elaboration of Product classes Organic: – Relatively small groups • working to develop well-understood applications. Semidetached: – Project team consists of a mixture of experienced and inexperienced staff. Embedded: – The software is strongly coupled to complex hardware, or real-time systems.
  • 183. COCOMO Model(CONT.) For each of the three product categories: – From size estimation (in KLOC), Boehm provides equations to predict: • project duration in months • effort in programmer-months Boehm obtained these equations: – examined historical data collected from a large number of actual projects.
  • 184. COCOMO Model(CONT.) Software cost estimation is done through three stages: – Basic COCOMO, – Intermediate COCOMO, – Complete COCOMO.
  • 185. Basic COCOMO Model(CONT.) Gives only an approximate estimation: – Effort = a1 (KLOC)a2 – Tdev = b1 (Effort)b2 • KLOC is the estimated kilo lines of source code, • a1,a2,b1,b2 are constants for different categories of software products, • Tdev is the estimated time to develop the software in months, • Effort estimation is obtained in terms of person months (PMs).
  • 186. Development Effort Estimation Organic : – Effort = 2.4 (KLOC)1.05 PM Semi-detached: – Effort = 3.0(KLOC)1.12 PM Embedded: – Effort = 3.6 (KLOC)1.20PM
  • 187. Development Time Estimation Organic: – Tdev = 2.5 (Effort)0.38 Months Semi-detached: – Tdev = 2.5 (Effort)0.35 Months Embedded: – Tdev = 2.5 (Effort)0.32 Months
  • 188. Basic COCOMO Model(CONT.) Effort is somewhat super-linear in problem size. Effort Size
  • 189. Basic COCOMO Model(CONT.) Development time – sublinear function of product size. When product size increases two times, – development time does not double. Time taken: – almost same for all the three product categories. Size Dev. Time 60K 18 Months 14 Months 30K
  • 190. Basic COCOMO Model(CONT.) Development time does not increase linearly with product size: – For larger products more parallel activities can be identified: •can be carried out simultaneously by a number of engineers.
  • 191. Basic COCOMO Model(CONT.) Development time is roughly the same for all the three categories of products: – For example, a 60 KLOC program can be developed in approximately 18 months • regardless of whether it is of organic, semi-detached, or embedded type. – There is more scope for parallel activities for system and application programs, • than utility programs.
  • 192. Example The size of an organic software product has been estimated to be 32,000 lines of source code. Effort = 2.4*(32)1.05 = 91 PM Nominal development time = 2.5*(91)0.38 = 14 months
  • 193. Intermediate COCOMO Basic COCOMO model assumes – effort and development time depend on product size alone. However, several parameters affect effort and development time: • Reliability requirements • Availability of CASE tools and modern facilities to the developers • Size of data to be handled
  • 194. Intermediate COCOMO For accurate estimation, – the effect of all relevant parameters must be considered: – Intermediate COCOMO model recognizes this fact: •refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers).
  • 195. Intermediate COCOMO(CONT.) If modern programming practices are used, – initial estimates are scaled downwards. If there are stringent reliability requirements on the product : – initial estimate is scaled upwards.
  • 196. Intermediate COCOMO(CONT.) Rate different parameters on a scale of one to three: –Depending on these ratings, •multiply cost driver values with the estimate obtained using the basic COCOMO.
  • 197. Intermediate COCOMO(CONT.) Cost driver classes: – Product: Inherent complexity of the product, reliability requirements of the product, etc. – Computer: Execution time, storage requirements, etc. – Personnel: Experience of personnel, etc. – Development Environment: Sophistication of the tools used for software development.
  • 198. Shortcoming of basic and intermediate COCOMO models Both models: – consider a software product as a single homogeneous entity: – However, most large systems are made up of several smaller sub-systems. • Some sub-systems may be considered as organic type, some may be considered embedded, etc. • for some the reliability requirements may be high, and so on.
  • 199. Complete COCOMO Cost of each sub-system is estimated separately. Costs of the sub-systems are added to obtain total cost. Reduces the margin of error in the final estimate.
  • 200. Complete COCOMO Example A Management Information System (MIS) for an organization having offices at several places across the country: – Database part (semi-detached) – Graphical User Interface (GUI) part (organic) – Communication part (embedded) Costs of the components are estimated separately: – summed up to give the overall cost of the system.
  • 201. Halstead's Software Science An analytical technique to estimate: – size, – development effort, – development time.
  • 202. Halstead's Software Science Halstead used a few primitive program parameters – number of operators and operands Derived expressions for: – over all program length, – potential minimum volume • Potential volume (V*) – actual volume, – language level, • Program level (L) as L = V* /V – Effort(V/L), and – development time.
  • 203. Example If the estimated development time is 1 year, then in order to develop the product in 6 months, – the total effort and hence the cost increases 16 times. – In other words, •the relationship between effort and the chronological delivery time is highly nonlinear.
  • 204. Scheduling Once tasks (from the WBS) and size/effort (from estimation) are known: then schedule Primary objectives • Best time • Least cost • Least risk Secondary objectives • Evaluation of schedule alternatives • Effective use of resources • Communications
  • 205. Terminology Precedence: • A task that must occur before another is said to have precedence of the other Concurrence: • Concurrent tasks are those that can occur at the same time (in parallel) Leads & Lag Time • Delays between activities • Time required before or after a given task
  • 206. Terminology Milestones – Have a duration of zero – Identify critical points in your schedule – Shown as inverted triangle or a diamond – Often used at “review” or “delivery” times • Or at end or beginning of phases • Ex: Software Requirements Review (SRR) • Ex: User Sign-off – Can be tied to contract terms
  • 208. Terminology Slack & Float – Float & Slack: synonymous terms – Free Slack – Slack an activity has before it delays next task – Total Slack – Slack an activity has before delaying whole project – Slack Time TS = TL – TE • TE = earliest time an event can take place • TL = latest date it can occur w/o extending project‟s completion date
  • 209. Scheduling Techniques – Mathematical Analysis • Network Diagrams – PERT – CPM – GERT – Bar Charts • Milestone Chart • Gantt Chart
  • 210. Network Diagrams Developed in the 1950‟s A graphical representation of the tasks necessary to complete a project Visualizes the flow of tasks & relationships
  • 211. Mathematical Analysis PERT – Program Evaluation and Review Technique CPM – Critical Path Method Sometimes treated synonymously All are models using network diagrams
  • 213. Network Diagrams Two classic formats – AOA: Activity on Arrow – AON: Activity on Node Each task labeled with • Identifier (usually a letter/code) • Duration (in std. unit like days) There are other variations of labeling There is 1 start & 1 end event Time goes from left to right
  • 215. Network Diagrams AOA consists of • Circles representing Events – Such as „start‟ or „end‟ of a given task • Lines representing Tasks – Thing being done „Build UI‟ • a.k.a. Arrow Diagramming Method (ADM) AON • Tasks on Nodes – Nodes can be circles or rectangles (usually latter) – Task information written on node • Arrows are dependencies between tasks • a.k.a. Precedence Diagramming Method (PDM)
  • 216. Critical Path “The specific set of sequential tasks upon which the project completion date depends” – or “the longest full path” All projects have a Critical Path Accelerating non-critical tasks do not directly shorten the schedule
  • 218. CPM Critical Path Method – The process for determining and optimizing the critical path Non-CP tasks can start earlier or later w/o impacting completion date Note: Critical Path may change to another as you shorten the current Should be done in conjunction with the you & the functional manager
  • 219. 4 Task Dependency Types Mandatory Dependencies • “Hard logic” dependencies • Nature of the work dictates an ordering • Ex: Coding has to precede testing • Ex: UI design precedes UI implementation Discretionary Dependencies • “Soft logic” dependencies • Determined by the project management team • Process-driven • Ex: Discretionary order of creating certain modules
  • 220. 4 Task Dependency Types External Dependencies • Outside of the project itself • Ex: Release of 3rd party product; contract signoff • Ex: stakeholders, suppliers, Y2K, year end Resource Dependencies • Two task rely on the same resource • Ex: You have only one DBA but multiple DB tasks
  • 221. Task Dependency Relationships Finish-to-Start (FS) – B cannot start till A finishes – A: Construct fence; B: Paint Fence Start-to-Start (SS) – B cannot start till A starts – A: Pour foundation; B: Level concrete Finish-to-Finish (FF) – B cannot finish till A finishes – A: Add wiring; B: Inspect electrical Start-to-Finish (SF) – B cannot finish till A starts (rare)
  • 223. Forward Pass To determine early start (ES) and early finish (EF) times for each task Work from left to right Adding times in each path Rule: when several tasks converge, the ES for the next task is the largest of preceding EF times
  • 225. Backward Pass To determine the last finish (LF) and last start (LS) times Start at the end node Compute the bottom pair of numbers Subtract duration from connecting node‟s earliest start time
  • 228. Slack & Reserve How can slack be negative? What does that mean? How can you address that situation?
  • 229. Slack & Reserve Start Date Project Due Date Forward Pass A Backward Pass B Reserve Time Negative Slack
  • 230. Network Diagrams Advantages – Show precedence well – Reveal interdependencies not shown in other techniques – Ability to calculate critical path – Ability to perform “what if” exercises Disadvantages – Default model assumes resources are unlimited • You need to incorporate this yourself (Resource Dependencies) when determining the “real” Critical Path – Difficult to follow on large projects
  • 231. PERT Program Evaluation and Review Technique Based on idea that estimates are uncertain – Therefore uses duration ranges – And the probability of falling to a given range Uses an “expected value” (or weighted average) to determine durations Use the following methods to calculate the expected durations, then use as input to your network diagram
  • 232. PERT Start with 3 estimates – Optimistic • Would likely occur 1 time in 20 – Most likely • Modal value of the distribution – Pessimistic • Would be exceeded only one time in 20
  • 233. PERT Formula Combined to estimate a task duration
  • 234. PERT Formula Confidence Interval can be determined Based on a standard deviation of the expected time • Using a bell curve (normal distribution) For the whole critical path use
  • 235. PERT Example Confidence interval for P2 is 4 times wider than P1 for a given probability Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2) Description Planner 1 Planner 2 m 10d 10d a 9d 9d b 12d 20d PERT time 10.16d 11.5d Std. Dev. 0.5d 1.8d
  • 236. PERT Advantages – Accounts for uncertainty Disadvantages – Time and labor intensive – Assumption of unlimited resources is big issue – Lack of functional ownership of estimates – Mostly only used on large, complex project Get PERT software to calculate it for you
  • 237. CPM vs. PERT Both use Network Diagrams CPM: deterministic PERT: probabilistic CPM: one estimate, PERT, three estimates PERT is infrequently used
  • 238. Milestone Chart Sometimes called a “bar charts” Simple Gantt chart – Either showing just highest summary bars – Or milestones only
  • 241. Gantt Chart Disadvantages – Does not show interdependencies well – Does not uncertainty of a given activity (as does PERT) Advantages – Easily understood – Easily created and maintained Note: Software now shows dependencies among tasks in Gantt charts – In the “old” days Gantt charts did not show these dependencies, bar charts typically do not
  • 242. Reducing Project Duration How can you shorten the schedule? Via – Reducing scope (or quality) – Adding resources – Concurrency (perform tasks in parallel) – Substitution of activities
  • 243. Compression Techniques Shorten the overall duration of the project Crashing • Looks at cost and schedule tradeoffs • Gain greatest compression with least cost • Add resources to critical path tasks • Limit or reduce requirements (scope) • Changing the sequence of tasks Fast Tracking • Overlapping of phases, activities or tasks that would otherwise be sequential • Involves some risk • May cause rework
  • 244. Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur. – Project risks affect schedule or resources – Product risks affect the quality or performance of the software being developed – Business risks affect the organisation developing or procuring the software
  • 245. The risk management process Risk identification – Identify project, product and business risks Risk analysis – Assess the likelihood and consequences of these risks Risk planning – Draw up plans to avoid or minimise the effects of the risk Risk monitoring – Monitor the risks throughout the project
  • 246. Levels of Risk Management 1. Crisis Management - everything‟s broken 2. Fix on failure - something broke? Fix it! 3. Risk mitigation - what will we do when it breaks?
  • 247. Levels of Risk Management 4. Prevention - how keep it from breaking? 5. Eliminate root causes - why could it break? PLEASE strive for the last two levels
  • 248. Risk Assessment & Control Risk Assessment – Identification – what are the risks? Make a list! (Or borrow one for ideas) – Analysis – assess risk likelihood and impact; find possible alternatives – Prioritization – which risks to focus on? Sort risks by impact ...
  • 249. Risk Assessment & Control Risk Control – Management planning – mitigation planning, ensure consistency among plans – Resolution – actively manage and resolve each risk when it occurs – Monitoring – track progress toward risk resolution; and identify new risks
  • 250. Risk Identification Look for risks – In all of the major areas of the project - resources, tools, process, and product – In management areas - cost, schedule, level of effort – In the Classic Mistakes and Fundamentals – In every area your customer cares about!
  • 251. Risk Identification Categories of schedule risks – Schedule creation – Organization and management – Development environment – End users – Customers – Contractors – ...
  • 252. Risk Identification More schedule risks – Requirements – Product – External environment – Personnel – Design and implementation – Process
  • 253. Risk Identification Risk identification has two different meanings: – Define what risks might occur (as previously described), and then analyze them – Be able to tell when a risk has taken place (which sets the stage for risk monitoring and mitigation)
  • 254. Risks and risk types R is k t y p e P o s s ib le r is k s T e c h n o lo g y T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p r o c e s s a s m a n y tr a n s a c tio n s p e r s e c o n d a s e x p e c te d . S o ftw a r e c o m p o n e n ts w h ic h s h o u ld b e r e u s e d c o n ta in d e fe c ts w h ic h lim it th e ir fu n c tio n a lity . P e o p le It is im p o s s ib le to r e c r u it s ta ff w ith th e s k ills r e q u ir e d . K e y s ta ff a r e ill a n d u n a v a ila b le a t c r itic a l tim e s . R e q u ir e d tr a in in g fo r s ta ff is n o t a v a ila b le . O r g a n is a tio n a l T h e o r g a n is a tio n is r e s tr u c tu r e d s o th a t d iffe r e n t m a n a g e m e n t a r e r e s p o n s ib le fo r th e p r o je c t. O r g a n is a tio n a l fin a n c ia l p r o b le m s fo r c e r e d u c tio n s in th e p r o je c t b u d g e t. T o o ls T h e c o d e g e n e r a te d b y C A S E to o ls is in e ffic ie n t. C A S E to o ls c a n n o t b e in te g r a te d . R e q u ir e m e n ts C h a n g e s to r e q u ir e m e n ts w h ic h r e q u ir e m a jo r d e s ig n r e w o r k a r e p r o p o s e d . C u s to m e r s fa il to u n d e r s ta n d th e im p a c t o f r e q u ir e m e n ts c h a n g e s . E s tim a tio n T h e tim e r e q u ir e d to d e v e lo p th e s o ftw a r e is u n d e r e s tim a te d . T h e r a te o f d e fe c t r e p a ir is u n d e r e s tim a te d . T h e s iz e o f th e s o ftw a r e is u n d e r e s tim a te d .
  • 255. Risk Analysis Risk Exposure (Impact) Calculation – Estimate Size of Loss; what is result of risk? – Estimate Probability of loss, based on corporate history, industry norms, or educated guesses – Multiply Size & Probability to get task Overrun due to that risk
  • 256. Risk Analysis – Add task Overrun to the estimated task duration – Repeat for every significant risk
  • 257. Risk analysis R is k P r o b a b ility E ffe c ts O rg a n is a tio n a l f in a n c ia l p ro b le m s f o rc e re d u c tio n s in th e p ro je c t b u d g e t. L o w C a ta s tro p h ic It is im p o s s ib le to re c ru it s ta f f w ith th e s k ills re q u ire d f o r th e p ro je c t. H ig h C a ta s tro p h ic K e y s ta f f a re ill a t c ritic a l tim e s in th e p ro je c t. M o d e ra te S e rio u s S o f tw a re c o m p o n e n ts w h ic h s h o u ld b e re u s e d c o n ta in d e f e c ts w h ic h lim it th e ir f u n c tio n a lity . M o d e ra te S e rio u s C h a n g e s to re q u ire m e n ts w h ic h re q u ire m a jo r d e s ig n re w o rk a re p ro p o s e d . M o d e ra te S e rio u s T h e o rg a n is a tio n is re s tru c tu re d s o th a t d if f e re n t m a n a g e m e n t a re re s p o n s ib le f o r th e p ro je c t. H ig h S e rio u s T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p ro c e s s a s m a n y tra n s a c tio n s p e r s e c o n d a s e x p e c te d . M o d e ra te S e rio u s T h e tim e re q u ire d to d e v e lo p th e s o f tw a re is u n d e re s tim a te d . H ig h S e rio u s C A S E to o ls c a n n o t b e in te g ra te d . H ig h T o le ra b le C u s to m e rs f a il to u n d e rs ta n d th e im p a c t o f re q u ire m e n ts c h a n g e s . M o d e ra te T o le ra b le R e q u ire d tra in in g f o r s ta f f is n o t a v a ila b le . M o d e ra te T o le ra b le T h e ra te o f d e f e c t re p a ir is u n d e re s tim a te d . M o d e ra te T o le ra b le T h e s iz e o f th e s o f tw a re is u n d e re s tim a te d . H ig h T o le ra b le T h e c o d e g e n e ra te d b y C A S E to o ls is in e f f ic ie n t. M o d e ra te In s ig n if ic a n t
  • 258. Risk Exposure Calculation Suppose task 3.6, “Define requirements for GUI”, has an estimated duration of 30 days.
  • 259. Risk Exposure Calculation If we know, based on historic data, that there is a 20% chance of this task running over by 10 days, the task overrun is 0.20*10 = 2 days. Hence in the schedule we should allow 30 + 2 = 32 days for this task, not just 30.
  • 260. Risk Prioritization Sort risks by descending task overrun This will automatically identify risks with the highest task overrun Focus on those risks most, since you have the most to lose if you don‟t!
  • 261. Risk Control Risk Management Planning Risk Resolution Risk Monitoring
  • 262. Risk Management Planning For each risk, identify how risk is to be identified, managed, monitored, and closed out. Consider: – What is the risk, – Where and When might the risk occur, – Who is responsible for managing that risk, – Why does the risk exist, and – How will the risk be handled if it occurs?
  • 263. Risk Management Planning Similar to security analysis: – Identify threats – Prevent threats – Detect threats (not trivial with information systems!) – Mitigate (reduce) the effects of the threats
  • 264. Risk Resolution Avoid the risk (have someone else do it) Transfer risk to another area (e.g. redesign) Investigate the risk to better understand it (e.g. use prototype or consultant to clarify) Eliminate the cause of the risk (defect prevention) ...
  • 265. Risk Resolution Assume the risk will occur and cope with minor impact Publicize the risk - well known risks are easier to avoid, and less shocking if they do occur Control the risk - implement mitigation strategy Remember the risk - keep lessons learned!
  • 266. Risk Monitoring Develop and maintain top 10 risk list Conduct postmortems after each major project event (milestone) - collect and record lessons learned Assign a risk officer - a devil‟s advocate, if you will - to keep pestering with “what if...” situations Don‟t be afraid to discuss risks openly
  • 267. Top 10 Risks List Develop a list of the ten most serious risks, their status, and mitigation plans Review and update each week Raises awareness of risks, and helps detect (identify) them
  • 268. Risk Management Tasks Develop Risk Management Plan – May take from one week to several months, depending on project size – Results in approval of Risk Management Plan
  • 269. Risk Management Tasks Update Risk List at a weekly status meeting – Update existing risks, add new ones as needed Reevaluate Risk Management Plan every 3 months to year, depending on project size
  • 270. Risk Management Tasks Be sure to account for the following ongoing risk management activities: – Risk identification (what could happen?) – Risk management planning • Risk analysis and prioritization (what would result?) – Risk resolution (mitigation strategy) – Risk monitoring (has it happened?)
  • 271. Risk Management Tasks For each risk, describe: – Risk number, name, and description – The Loss Hours, Probability, and Impact of each risk; sorted by descending Impact – How each risk will be: prevented (keep it from happening), identified (know when it has happened), and mitigated (managed once it has happened)
  • 273. Content Software Development Process Informal Review Software Inspection Process Performed Software Inspections Results Experience Conclusions and Future
  • 274. SW Development Process identify needs & common issues, define priorities and work-plan, define components perform pre-design investigations -> identify candidate technologies/techniques develop high-level design refine design, implement code 180,000 lines of C++ 40 % generated unit test components integrate with other subsystems Total 800 000 lines incl. external sw Collect Requirements Pre-design Investigations High-level Design Testing & Integration Detailed Design Implementation Training, Programming and Testing Tools, FrameMaker, html, SRT Configuration Management, StP/OMT CASE TOOLS Software Development Environment
  • 275. Review - Inspection Review: • Presentation of each SW Component to the Group in each Development Phase • Discussion and Coordination with other components • Goal: Clarification and Accept/Reject Decision Inspection: • Quality Improvement Process to the software project • Goal: Defect Detection & Defect Prevention
  • 276. Informal Review From the start of the project – document preparation and monthly open meetings • present status, results, proposals • inform colleagues - receive feedback • suggestions -> enhancements -> acceptance Results: – Coherent set of end-product components – Increased communication Drawback: – Lack of time of reviewers – No code review
  • 277. Inspection in the SDP Document Inspection Document Inspection Document Inspection Code Inspection Document Inspection Applying Testing Tools Code Inspection Requirements Design Test ImplementationImplementation Test Test Plan
  • 278. Inspection - Objectives Defect Detection – documents are checked for cleanness and consistency against rules Defect Prevention – learning from defects found – suggesting improvements On the Job Training – education in standards and rules – apply creativity
  • 279. Sources Inspection Process Map Planning & Entry Kick-off Meeting Checking Logging Meeting Brainstorming Edit Exit Follow-up Inspection Plan Issue log tables Action Lists Exit Product Data Summary Change Requests Product Rules Checklists
  • 280. List of performed Inspections Requirement Inspection • DS - Diagnostic System • IGUI - Integrated Graphical User Interface • DAL - Data Access Library Design Inspection • TM - Test Manager • DS - Diagnostic System Code Inspection • IPC - Inter Process Communication • MRS - Message Reporting System • IS - Information Service • DAL - Data Access Library 180 pages of documents 8000 lines of code
  • 281. Results: Issue log table Each issue is logged, discussed, checked Emphasis on non-trivial issues Per Inspection : 10 to 200 issues found Number of recorded issue logs depend on: • Type of Inspection • Phase of Project • Entry conditions • Experience of Inspectors • Counting system -> Improved Code -> Improved Documentation
  • 282. Inspection Process Results Change Requests – To Rules for Requirements, Design or Coding use of ’shall’ ’should’ ’may’ for Requirements adopt standard command line parameters use of coding conventions program exit status convention – To the Inspection Procedure Suggestions about editor comment types possible strategy on rule checking Action Lists – Actions to be performed outside the Inspection Process – Questions to be clarified, i.e. beyond the scope of Inspection
  • 283. Observations Requirements • most important, the first in the chain: • a bug may propagate to the end -> unwanted results even with perfect code Design • the hardest to inspect • difficult to provide a good set of guidelines Code • most time consuming: Code & Documentation, mother documents & reference documents • Good set of rules, Use of automatic checking tools
  • 284. Adaptation to Environment Everything is allowed • which helps improving – process – product – communication – cooperation, education – integration, coherence while keeping Consistency • improving Efficiency HEP: geographically distributed no specialized expertise little formal training little hierarchical power participation by conviction
  • 285. Efficiency - Flexibility Efficiency • Inspection is time consuming • - don‟t waste time and effort of inspectors • Careful planning and Clear Instructions • Solid Process Framework • Inspect Samples • Motivation of peers Flexibility • Build in change Management • Well defined procedure • - but each inspection to be handled individually
  • 286. Experience Inspection is Take fears seriously Explain aims Respect privacy Demonstrate helpfulness Participation Trust amongst colleagues Constructive criticism Integration Common working culture Fear to be criticized and judged
  • 287. Conclusions Reviews prepare the ground and stabilize SDP Adaptation of the inspection method for the Environment Gain in quality and experience Appreciated by authors and peers Help for team building in a distributed environment
  • 288. Future Good understanding for the next phase: – stabilize inspection process and keep style – provide a helpful framework based on experience – use it through entire development cycle – „lighter‟ inspection - faster turnaround time – use sampling techniques – keep real logging meetings where possible – provide metrics – stay flexible and efficient
  • 289. Closing Process Administrative Closure Contract Close-out Formalizing acceptance of the project or phase and bringing it to an orderly end