Software project management

1. Recent and Future Trends

2. Continuous
Integration

3. Introduction
• Continuous Integration was first introduced in the year 2000 with the software known as
Cruise Control.
• Over the years, Continuous Integration has become a key practice in any software
organization.
• This is a development practice that calls upon development teams to ensure that a build
and subsequent testing is conducted for every code change made to a software program.
This concept was meant to remove the problem of finding late occurrences of issues in the
build lifecycle.
• Instead of the developers working in isolation and not integrating enough, Continuous
Integration was introduced to ensure that the code changes and builds were never done in
isolation.

5. Why Continuous Integration?
• The continuous Integration process helps to answer the following questions for the
software development team.
• Do all the software components work together as they should? – Sometimes systems
can become so complex that there are multiple interfaces for each component. In
such cases, it’s always critical to ensure that all the software components work
seamlessly with each other.
• Is the code too complex for integration purposes? – If the continuous integration
process keeps on failing, there could be a possibility that the code is just too
complex. And this could be a signal to apply proper design patterns to make the code
lesser complex and more maintainable.

6. Continue
• Does the code adhere to the established coding standards? – Most of the test cases will
always check that the code is adhering to the proper coding standards. By doing an
automated test after the automated build, this is a good point to check if the code meets
all the desired coding standards.
• How much code is covered by automated tests? – There is no point in testing code if the
test cases don’t cover the required functionality of the code. So it’s always a good
practice to ensure that the test cases written should cover all the key scenarios of the
application.
• Were all the tests successful after the latest change? – If a test fails, then there is no
point in proceeding with the deployment of the code, so this is a good point to check if
the code is ready to move to the deployment stage or not.

7. Workflow

8. Continuous Integrations Tools
• Jenkins (Hudson)
• TravisCI
• Cruise Control
• TeamCity
• BuildBot
• Bamboo
• Team foundation server
• Gerrit

9. Early Risk Resolution

10. Introduction To Risk
• Risk is the possibility of suffering loss.
• In a development project, the loss describes the impact to the project which could
be in the form of diminished quality of the end product, increased costs, delayed
completion, or failure.

11. Introduction to Early Risk Resolution
• The engineering stage of the life cycle (inception and elaboration phases) focuses on
confronting the risks and resolving them before the big resource commitments of the
production stage.
• Conventional projects usually do the easy stuff first, thereby demonstrating early
progress. A modern process attacks the important 20% of the requirements, use
cases, components, and risks.

12. Continue
• The effect of the overall life-cycle philosophy on the 80/20 lesson provides a useful
risk management perspective.
• 80% of the engineering is consumed by 20% of the requirements.
• 80% of the software cost is consumed by 20% of the components.
• 80% of the errors are caused by 20% of the components.
• 80% of the progress is made by 20% of people.

13. Why Do we need Early Risk Resolution
• Assess continuously what can go wrong (risks identification and assessment).
• Determine what risks are important to deal with (risk prioritization).
• Implement strategies to deal with those risk (risk resolution).
• Ensure that high priority risks are aggressively managed and that all risks are
cost-effectively managed throughout the project.

14. Evolutionary
Requirements

15. • Requirements are capabilities and conditions to which the system—and more broadly, the
project—must conform.
• A prime challenge of requirements work is to find, communicate, and remember.
• The UP promotes a set of best practices, one of which is manage requirements.
• This does not refer to the waterfall attitude of attempting to fully define and stabilize the
requirements in the first phase of a project, but rather— in the context of inevitably
changing and unclear stakeholder’s wishes– “a systematic approach to finding,
documenting, organizing, and tracking the changing requirements of a system”.
Introduction

16. Evolutionary Vs Waterfall Requirements
• Notice the word changing in the definition of what it means to manage requirements.
• The UP embraces change in requirements as a fundamental driver on projects.
• That’s incredibly important and at the heart of waterfall versus iterative and
evolutionary thinking.

17. Skillful Means to Find Requirements
• Besides changing, the word finding is important; that is, the UP encourages skillful
elicitation via techniques
• such as writing use cases with customers, requirements workshops that include both
developers and customers, focus groups with proxy customers, and a demo of the
results of each iteration to the customers, to solicit feedback

18. Types and Categories of Requirements
• Functional—features, capabilities, security.
• Usability—human factors, help, documentation.
• Reliability—frequency of failure, recoverability, predictability.
• Performance—response times, throughput, accuracy, availability, resource usage.
• Supportability—adaptability, maintainability, internationalization, configurability.

19. The “+” in FURPS +Indicates ancillary and sub
factors such as
• Implementation—resource limitations, languages and tools, hardware,…
• Interface—constraints imposed by interfacing with external systems.
• Operations—system management in its operational setting.
• Packaging—for example, a physical box.
• Legal—licensing and so forth.

20. Continue
• It is helpful to use FURPS+ categories as a checklist for requirements coverage, to
reduce the risk of not considering some important facet of the system.
• In common usage, requirements are categorized as functional or nonfunctional
• Some dislike this broad generalization, but it is very widely used

21. Functional Requirements
• Functional requirements are explored and recorded in the Use-Case Model, In the
system features list of the Vision artifact.
• Other requirements can be recorded in the use cases they relate to, or in the
Supplementary Specifications artifact.

22. Teamwork among
Stakeholders

23. Stakeholder and Teamwork's
• Stakeholder is any individual or an organization that is actively involved in a
project, or whose interest might be affected (positively or negatively) as a result of
project execution or completion.
• Teamwork is working in partnership with others toward a common goal, a
combined action of various individuals, or even just efficient and effective
combination with other people.
However, just because people working with one another doesn’t mean that they’re
participating into a successful teamwork.

24. Four steps of Stakeholders Management to
complete task of project
• Step 1: Identify Your Stakeholders
• Step 2: Determine a Stakeholder’s Influence
• Step 3: Develop a Communication Management Plan
• Step 4: Engage With Your Stakeholders

25. Stake Holder Roles
• User:- Define the system’s functionality and ultimately make use of it.
• Tester:- Test the system to ensure that it is suitable for use.
• Developer:- construct and deploy the system from specification.
• Other Roles:-
• Quick and easy problem solving.
• Strong staff relationships.
• Healthy competition.

26. Benefits of Teamwork
• Saves time.
• Generate more brilliant and creative idea.
• Encourage healthy risk-taking.
• Attention to Results
• Confront of Accountability
• Fearless In Conflict’s
• Presence of Trust

27. Effectively Managing Stakeholders

28. Top 10 Software Management
Principles

29. 1: Base the process on an architecture first
approach:
• To start the software development, the developer first thoroughly identifies the
requirements then chooses the significant design decision.
• Before starting with the lifecycle (development) process check the selected
resources are sufficient for complete software development.

30. 2:Establish iterative lifecycle process
that face risk early:
• Today the organizations not follow to define the entire problem at once, design the
entire solution, build the software, then test and deploy in sequence.
• The organizations adopt follows iterative development approach which facilitates,
problem understanding, effective solution, and an effective plan over several
iterations.
• It also balances the stockholder’s objectives. The main advantage of iterative
approach is risks are identified early to avoid software scrap and rework.

31. 3:Transition design methods to highlight
Component based development:
• The developers should transits from line-of-code mentality to component based
mentality to reduce the amount of human generated code and custom development.
• A component based model is unified set of interface and behavior. Pre-existing
line of code either in source or executable format, with a defined

32. 4: Establish change management
environment:
• The dynamics of iterative development, concurrent workflows require the
controlled baselines.

33. 5: Enhance change freedom through tools
that support round trip engineering
(iterative):
• The iterative development process supports automate and synchronize engineering
information in different formats.
• Without substantial automation, change management, documentation, and testing
it is difficult to reduce project development time.
• Change freedom is necessity in iterative process at the same time the role of
environment is crucial.

34. 6: Capture design artifacts in rigorous,
model based notion:
• Generally model based approach supports rich graphical and textual design
notions.
• Visual modeling and formal machine processable language provides good
measures than traditional design approach.

35. 7: Instrument the process for objective quality
control and progress assessment:
• Project development progress and the quality should be assessed in the middle of
the development lifecycle.
• The best assessment mechanisms are derived directly from the engineering
artifacts and able to integrate all the activities in the development process.

36. 8: Use demonstration based approach to
assess intermediate artifacts:
• Transit from current development artifacts to executable one to early elimination
of architectural defects.

37. 9:Plan intermediate releases in groups of
usage situations with evolving levels of
detail:
• It is necessary that the software management process has continuous
demonstrations within the operational context.
• The evolution of project increments and generations must be equal with current
level of understanding of requirements and architecture.

38. 10: Establish configurable process that is
economically scalable:
• No single process is suitable for software development. A practical process
framework must be organizing a broad spectrum of applications.
• The software development process must integrate economy of scale, development
automation, architecture patterns and components.

39. Software Management Best
Practices

40. • Software Engineering Process
• A disciplined approach to assigning and managing tasks and responsibilities in
a development organization
• goal is to produce a software that is:
• Within a predictable schedule and budget
• High-quality
• Correspondent to the needs of its end users
• People involved in software development:
• Project managers
• Developers •Qualities engineers
• Process engineers
• Method specialists
• System engineers Analysts

41. Symptoms of Software Development Failure
• Inaccurate understanding of end-user needs
• Inability to deal with changing requirements
• Modules that don't fit together
• Software that's hard to maintain or extend
• Late discovery of serious project flaws
• Poor software quality
• Unacceptable software performance
• Team members in each other's way, making it impossible to reconstruct who
changed what, when, where, and why
• An untrustworthy build-and-release process.

42. Root Causes of Software Development
Problems
• Ad hoc requirements management
• Ambiguous and imprecise communication
• Brittle architectures
• Overwhelming complexity
• Undetected inconsistencies in requirements, designs, and implementations
• Insufficient testing
• Subjective assessment of project status
• Failure to attack risk
• Uncontrolled change propagation
• Insufficient automation

43. Software Best Practices
• Treat root causes of problems to eliminate symptoms.
• To develop and maintain quality software in a repeatable and predictable fashion
Successful organizations use best practice as follows:
• Develop software iteratively
• Manage requirements
• Visually model software
• Continuously verify software quality
• Control changes to software

44. Develop Software Iteratively
• It offers solutions to the root causes of the software development problem
• Serious misunderstandings are made evident early in the lifecycle (when it’s
possible to react to them).
• It enables and encourages user feedback so as to elicit the system’s real
requirements.
• The development team is forced to focus on those issues that are most critical to
the project and are shielded from those issues that distract them from the project's
real risks.

45. Manage Requirements
• A requirement is a condition or capability a system must have.
• The challenge of managing the requirements is how to deal with the change of
requirements during the life of a software process.
• It is hard to completely and exhaustively state a system's requirements before the
start of development.
• As a new or evolving system changes, a user's understanding of the system's
requirements also changes.

46. Visually Model Software
• A model is a simplification of reality that completely describes a system from a
particular perspective.
• Model helps development team visualize, specify, construct, and document the
structure and behavior of a system's architecture.
• Visual modeling also helps to maintain consistency among a system's artifacts: its
requirements, designs, and implementations.
• Modeling software visually offers solutions to the root causes of the software
development problems.

47. Continuously Verify Software Quality
• Software problems are 100 to 1,000 times more expensive to find and repair after
deployment than beforehand.
• It's important to assess continuously the quality of a system with respect to its:
functionality, reliability, application performance, and system performance.
• Verifying a system's functionality involves creating tests for each key scenario,
each of which represents some aspect of the system's desired behavior. As
software is developed iteratively, tests are performed at every iteration.

48. Control Changes to Software
• A key challenge to developing software-intensive systems is to cope with
developers organized into teams. In the absence of disciplined control, the
development process rapidly degenerates into chaos.
• Coordinating activities and artifacts of developers and teams involves establishing
repeatable workflows for managing changes to software.
• Coordination allows a better allocation of resources based on the project's
priorities and risks.

49. Next Generation Cost
Models

50. Introduction
• A next generation software cost model should explicitly separate architectural
engineering from application production, just as an architecture-first process does.
• The cost of designing, producing, testing, and maintaining the architecture
baseline is a function of scale, quantity ,quality, technology, process and team skill
• Software experts hold widely varying opinions about software economics and its
manifestation in software cost estimation models:
• Source lines of code versus function points.
• Economy of scale versus diseconomy of scale.

51. Effort = F( TArch, SArch ,QArch,PArch ) + F(TApp,SApp,QApp,PApp)
Time = F( PArch, EffortArch) + F( PApp ,EffortApp )
Where,
T = technology parameter
S = scale parameter
Q = quality parameter
P = Process parameter

52. Engineering Stage
• Risk resolution, low-fidelity plain,
schedule/technology-driven, risk sharing
contracts
• Team Size:
• Architecture: Small team of software
engineers Application: Small team of
domain engineers Small and expert as
possible
• Product: Executable architecture,
Production plans, Requirements
• Focus: Design and integration, host
development environment
• Phases: Inception and elaboration
Production Stage
• Low risk, high-fidelity plan, cost-driven
Fixed-price contracts/funding
• Team Size:
• Architecture: Small team of software
engineers Application: As many as
needed Large and diverse as possible
• Product: Deliverable, useful function,
tested baselines, warranted quality
• Focus: Implement, test and maintain ,
Target technology
• Phases: Construction and transition

53. Modern Software Economics, Cultural
Impact and Denouement

54. Modern Software Economics
• Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the problem in early design phases.
• You can compress software development schedules 25% of nominal, but no more.
• For every $1 you spend on development, you will spend $2 on maintenance.
• Software development and maintenance costs are primarily a function of the
number of source line of code.
• Variations among people account for the biggest difference in software
productivity.

55. • Only about 15% of software development effort is devoted to programming.
• Software systems and product typically cost times as much per SLOC as
individual software programs. Software-system product- an economy of scale is
achievable.
• Walkthroughs catch 60% of the errors.
• 80% of the contribution comes from 20 % of the contributors.
• The overall ratio of software to hardware costs is still growing. In 1955, it was
15:85; in 1985, 85:15.

56. Culture Shifts
• Lower level and mid-level manager are performers.
• Requirements ad designs are fluid and tangible.
• Ambitious demonstrations are encouraged.
• Good and bad project performance is much more obvious earlier in the cycle.
• Early increment will be immature.
• Artifacts are less important early, more important later.
• Real issues are surfaced and resolved systematically.
• Quality assurance is everyone’s job, not a separate discipline.
• Performance issues arise early in the life cycle.
• Investments in automation are necessary.
• Good software organization should be more profitable.

57. Denouement
• Sequentially transitioning from requirement to design to code to rest.
• Achieving 100% completeness of each artefact at each life-cycle stage.
• Treating all requirements, artifacts, components, and so forth, as equals.
• Achieving high-fidelity traceability among all artifacts at each stage in the life
cycle.

58. Modern Iterative development process Framework
• Continuous round-trip engineering from requirements to test at evolving levels of abstraction.
• Achieving high-fidelity understanding of the drivers(the 20%) as early as practical
• Evolving the artifacts in breadth and depth based on risk management priorities.
• Postponing completeness and consistency analyses until later in the life cycle.
• A better way to transition to a more mature iterative development process that supports automation
technologies and modern architectures is to take the following shots:-
• Ready - Do your homework.
• Aim – Select a critical project.
• Fire – Execute with vigor and follow-through.